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, [[email protected]]) 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 <[email protected]> Gerrit-Reviewer: Alon Bar-Lev <[email protected]> Gerrit-Reviewer: Dan Kenigsberg <[email protected]> Gerrit-Reviewer: Federico Simoncelli <[email protected]> Gerrit-Reviewer: Moran Goldboim <[email protected]> _______________________________________________ vdsm-patches mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/vdsm-patches
