Hide Forgot
Description of problem: - today when I build vdsm rpms, the rpms files looks as follows: vdsm4.9.2-0.104.gitd7a3421.fc16.noarch.rpm which is a combination of package name + version + git-hash. this makes the update\upgrade process a bit problematic (yum doesn't like\refuse to deal with it). when building libvirt, their rpm looks as follows: libvirt-0.9.9-1.fc16.x86_64.rpm which is quit normal, can track it, install\update. I suggest we do the same.
The following change was abandoned, I expect vdsm maintainer to implement his own version of cleaning up release cycle. 1. Release a version at vdsm-4.13.0 2. Release pre-releases and stanpshot at vdsm-4.13.0_suffix@SOMETHING@ We should not re-invent the wheel in versioning. --- build: closer to open source versioning and release cycle Upstream project version is constructed from three components: major, minor and fix. Major version is incremented when there is a significant change in project. Minor version is incremented when features are being added. Fix version is incremented when a stable fix is published. A project release is made at fix release 0, for example: 4.11.0 Pre-releases are marked as version suffix, for example the following is a valid release cycle: - 4.11.0_alpha - 4.11.0_beta - 4.11.0_beta2 - 4.11.0_rc - 4.11.0_rc2 - 4.11.0 Please remember, upstream releases sources, only sources. Downstream is allowed to add its own revision, for example rpm based distribution use the following format: @UPSTREAM_VERSION@-@DOWNSTREAM_VERSION@ Downstream versioning scheme should not effect upstream, as the flow has its nature. However, upstream may provide a reference for downstream packager. Due to limitation of rpm technology, the pre-release milestone component cannot be used as part of upstream version component, so a sequence should be added, for example, the following is a valid downstream release cycle: - 4.11.0-0.0.alpha - 4.11.0-0.1.beta - 4.11.0-0.2.rc - 4.11.0-1 Branch should contain the 'next' version with milestone of 'master'. Hence over time the master will go over the following transitions: - 4.11.0-0.0.master - 4.11.0-0.1.alpha - 4.11.0-0.2.master - 4.11.0-0.3.beta - 4.11.0-0.4.master - 4.11.0-0.5.rc - 4.11.0-0.6.master - 4.11.0-1 - 4.12.0-0.0.master This change enables this approach by adding the following variables to the configure.ac: - PRODUCT_VERSION - minor.major.fix - PRODUCT_VERSION_SUFFIX - optional suffix, such as _alpha - PACKAGE_RPM_RELEASE - rpm release Unlike current versioning implementation we disconnect the versioning from the git branch information, as the git branch information is aware of /past/ versions, while a branch is work toward the /next/ version. A valid sequence for release cycle: PRODUCT_VERSION=4.11.0 PRODUCT_VERSION_SUFFIX=_master PACKAGE_RPM_RELEASE=0.0.$(echo PRODUCT_VERSION_SUFFIX | sed 's/^_//') PRODUCT_VERSION=4.11.0 PRODUCT_VERSION_SUFFIX=_beta PACKAGE_RPM_RELEASE=0.1.$(echo PRODUCT_VERSION_SUFFIX | sed 's/^_//') PRODUCT_VERSION=4.11.0 PRODUCT_VERSION_SUFFIX=_master PACKAGE_RPM_RELEASE=0.2.$(echo PRODUCT_VERSION_SUFFIX | sed 's/^_//') PRODUCT_VERSION=4.11.0 PRODUCT_VERSION_SUFFIX=_rc PACKAGE_RPM_RELEASE=0.3.$(echo PRODUCT_VERSION_SUFFIX | sed 's/^_//') PRODUCT_VERSION=4.11.0 PRODUCT_VERSION_SUFFIX=_master PACKAGE_RPM_RELEASE=0.4.$(echo PRODUCT_VERSION_SUFFIX | sed 's/^_//') PRODUCT_VERSION=4.11.0 PRODUCT_VERSION_SUFFIX= PACKAGE_RPM_RELEASE=1 PRODUCT_VERSION=4.12.0 PRODUCT_VERSION_SUFFIX=_master PACKAGE_RPM_RELEASE=0.0.$(echo PRODUCT_VERSION_SUFFIX | sed 's/^_//') Build automation may inject release suffix to the binary package name, an example exist in the 'make rpm' target. Change-Id: I1a73089d47804ca31e3a4d80aaf811fa011ba1f3 Signed-off-by: Alon Bar-Lev <alonbl> http://gerrit.ovirt.org/#/c/12448/
(In reply to comment #1) > The following change was abandoned, I expect vdsm maintainer to implement > his own version of cleaning up release cycle. And I expect contributors to vdsm be less hasty to abandon a patch. A tiny sight of resistance or questioning by peers should not result in that.
(In reply to comment #2) > (In reply to comment #1) > > The following change was abandoned, I expect vdsm maintainer to implement > > his own version of cleaning up release cycle. > > And I expect contributors to vdsm be less hasty to abandon a patch. A tiny > sight of resistance or questioning by peers should not result in that. It is a simple task, you have your preferences, please apply them. You may use the proposed patch as a base or replace this entirely. The end result is well known, the implementation should be something you happy with, instead of long discussion the "just do it" approach should be easier for everyone.
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.