Change in vdsm[master]: build: closer to open source versioning and release cycle

danken at redhat.com danken at redhat.com
Thu Feb 28 20:13:37 UTC 2013


Dan Kenigsberg has posted comments on this change.

Change subject: build: closer to open source versioning and release cycle
......................................................................


Patch Set 1: (5 inline comments)

....................................................
Commit Message
Line 62:  - PACKAGE_RPM_RELEASE - rpm release
Line 63: 
Line 64: Unlike current versioning implementation we disconnect the versioning
Line 65: from the git branch information, as the git branch information is aware
Line 66: of /past/ versions, while a branch is work toward the /next/ version.
I care about a particular individual's (me) ability to discern what a specific version means. Maybe you can point to your reference projects, where things are done The Right Way.
Line 67: 
Line 68: A valid sequence for release cycle:
Line 69:  PRODUCT_VERSION=4.11.0
Line 70:  PRODUCT_VERSION_SUFFIX=_master


Line 62:  - PACKAGE_RPM_RELEASE - rpm release
Line 63: 
Line 64: Unlike current versioning implementation we disconnect the versioning
Line 65: from the git branch information, as the git branch information is aware
Line 66: of /past/ versions, while a branch is work toward the /next/ version.
I'm lazy, that's true. But besides that, I dislike redundant data and boring commits with "bump version for future release" only followed by a "unbump version for a quick fix release".
Line 67: 
Line 68: A valid sequence for release cycle:
Line 69:  PRODUCT_VERSION=4.11.0
Line 70:  PRODUCT_VERSION_SUFFIX=_master


....................................................
File configure.ac
Line 18: # Refer to the README and COPYING files for full details of the license
Line 19: #
Line 20: 
Line 21: # Autoconf initialization
Line 22: define([PRODUCT_VERSION], [4.11.0])
"rc", being "release candidate" is not such a great term - it's too early to use it just after the former release. But yeah, I suppose something in this spirit could work.
Line 23: define([PRODUCT_VERSION_SUFFIX], [_master])
Line 24: AC_INIT([vdsm], PRODUCT_VERSION[]PRODUCT_VERSION_SUFFIX, [vdsm-devel at lists.fedorahosted.org])
Line 25: AC_CONFIG_AUX_DIR([build-aux])
Line 26: 


Line 26: 
Line 27: m4_include([m4/ax_python_module.m4])
Line 28: 
Line 29: # RPM version
Line 30: PACKAGE_RPM_VERSION="PRODUCT_VERSION"
Sorry, I do not understand your answer. The only thing that is using PRODUCT_RPM_VERSION is vdsm.spec.in, and it could have used PRODUCT_VERSION just as well (as it does before your patch).
Line 31: PACKAGE_RPM_RELEASE="0.0.$(echo PRODUCT_VERSION_SUFFIX | sed 's/^_//')"
Line 32: AC_SUBST([PACKAGE_RPM_VERSION])
Line 33: AC_SUBST([PACKAGE_RPM_RELEASE])
Line 34: 


....................................................
File Makefile.am
Line 84: 
Line 85: srpm: dist
Line 86: 	SUFFIX=".`date -u +%Y%m%d%H%M%S`"; \
Line 87: 	if [ -d "$(top_srcdir)/.git" ]; then \
Line 88: 		SUFFIX="$$SUFFIX.git`GIT_DIR="$(top_srcdir)/.git" $(GIT) rev-parse --short=16 HEAD`"; \
Yeah, I saw that you've already agreed to use 7 chars.

I find it odd that a build from a unique git hash brings about different artifacts, depending on the build date, and try to think of another monotonously-rising function.
Line 89: 	fi; \
Line 90: 	rpmbuild \
Line 91: 		-ts \
Line 92: 		--define="release_suffix $$SUFFIX" \


--
To view, visit http://gerrit.ovirt.org/12448
To unsubscribe, visit http://gerrit.ovirt.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I1a73089d47804ca31e3a4d80aaf811fa011ba1f3
Gerrit-PatchSet: 1
Gerrit-Project: vdsm
Gerrit-Branch: master
Gerrit-Owner: Alon Bar-Lev <alonbl at redhat.com>
Gerrit-Reviewer: Alon Bar-Lev <alonbl at redhat.com>
Gerrit-Reviewer: Dan Kenigsberg <danken at redhat.com>
Gerrit-Reviewer: Federico Simoncelli <fsimonce at redhat.com>
Gerrit-Reviewer: Moran Goldboim <mgoldboi at redhat.com>


More information about the vdsm-patches mailing list