Bug 782735

Summary: [ovirt] [vdsm] please generate conventional rpm version when running make rpm
Product: [Retired] oVirt Reporter: Haim <hateya>
Component: vdsmAssignee: Dan Kenigsberg <danken>
Status: CLOSED WONTFIX QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: abaron, acathrow, alonbl, bazulay, iheim, jkt, mgoldboi, yeylon
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: infra
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-12-01 09:06:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Haim 2012-01-18 10:17:16 UTC
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.

Comment 1 Alon Bar-Lev 2013-03-12 10:51:51 UTC
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/

Comment 2 Dan Kenigsberg 2013-03-12 11:37:59 UTC
(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.

Comment 3 Alon Bar-Lev 2013-03-12 11:41:57 UTC
(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.

Comment 4 Itamar Heim 2013-12-01 09:06:52 UTC
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.