Rework the versioning scheme

[zaytsev]

We have a problem with the current mc-x.y.z-preW versioning scheme for both Redhat and Debian. The problem is that
(1) mc-1:4.7.0-1.fc12.x86_64
(2) mc-1:4.7.0.pre4.231.g8cfffc5-1.fc12.x86_64
(1) is considered to be older than (2)
This issue is discussed quite frequently on the net:
​https://bugs.launchpad.net/openobject-client/+bug/314575
​http://mail.python.org/pipermail/distutils-sig/2009-January/010678.html
etc.

In OpenERP v5.0.0 the versioning for the pre-release candidates is made by adding a suffix to the "version" string. Eg: 5.0.0_rc3. This type of versioning conflicts with RPM ordering and updating (generated using 'bdist_rpm' target to setup.py). The final RPM release package, 5.0.0, will not update an RPM package identified as 5.0.0_rc3. How Fedora has been dealing with this is to put the pre-release candidate designation into a 'release' string in their spec files.
For example:
Pre-release candidate: rc2
Upstream: foo-5.0.0_rc2
Rpm Version: 5.0.0
Rpm Release: 0_rc2
Final release:
Upstream: foo-5.0.0
Rpm Version: 5.0.0
Rpm Release: 1
Now the final RPM release, 5.0.0-1, will update 5.0.0-0_rc2

My suggestion is to adopt the next scheme:
(1) mc-1:4.7.0-1.fc12.x86_64
(2) mc-1:4.7.0-0_pre4.231.g8cfffc5-1.fc12.x86_64

Version:        4.7.0
Release:        0_pre4.140.ge1a4559%{?dist}

[narcan]

I confirm this issue on Debian.
thanks

Denis Briand
Debian maintainer

[zaytsev]

​http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_packages

alsa-lib-0.9.2-0.1.beta1 (add a new patch on top of 0.9.2beta1)
alsa-lib-0.9.2-0.2.beta1 (upgrade to 0.9.2beta2)
alsa-lib-0.9.2-0.3.beta2 (upgrade to 0.9.2beta3)
alsa-lib-0.9.2-0.4.beta3 (add a new patch on top of 0.9.2beta3)
alsa-lib-0.9.2-0.5.beta3 (upgrade to 0.9.2rc1)
alsa-lib-0.9.2-0.6.rc1 (upgrade to 0.9.2rc2)
alsa-lib-0.9.2-0.7.rc2 (upgrade to 0.9.2 "final", version becomes normal)
alsa-lib-0.9.2-1 (add a new patch on top of 0.9.2 "final")
alsa-lib-0.9.2-2

Translates to:

mc-4.7.0-0.1.1.pre1
mc-4.7.0-0.1.2.pre1.gittag1
mc-4.7.0-0.1.3.pre1.gittag2
mc-4.7.0-0.1.4.pre1.gittag3
...
mc-4.7.0-0.1.128.pre1.gittag128
mc-4.7.0-0.2.1.pre2
...
mc-4.7.0-0.3.1.pre3
mc-4.7.0-0.4.1.pre4
...
mc-4.7.0-1

And everything will be fine.

We need an autotools expert.

[slavazanko]

Created branch 1905_versioning_scheme

Initial changeset:f8da5fe3ccbe6d10655189801fecf41bb1063ac5

Review, please.

[zaytsev]

Why would be just comply to Fedora Packaging Guidelines as I commented above? I discovered them after doing more research on the ticket, that's why I didn't update the description. That's not too hard, Slava, could you please tweak your branch accordingly?

[slavazanko]

See changeset:1a0c1d700598202317de3eddae3d9758d572dba5

[slavazanko]

Branch rebased into one commit.

• e63ddb17d14b8023eda2b4b4c582020cae04e4a8

Review, please.

[slavazanko]

Merge changeset:24d9c60b1fadfe5681ed3334e6ae8ebfe0c01a77

[metux]

Some general notes (not just to mc):

Version numbers should _always_ be an hierachic vector,
meaning [a,b+1,c,d] >> [a,b,c,d], etc.

Mathematically speaking: V=[a,b,c,d] <=> V*=(a*k^3)+(b*k2)+(c*k^1)+(d*k0).
(actually, that's how my Briegel build/packaging system, as well as OSS-QM, handles version numbers).

Upstream should only use the a,b,c elements and having d=0, leaving it to distro-internal revision.

We shouldnt do prereleases at all, betatesting should happen either directly on master or separate tags in their own namespace, or maybe deviding into odd/even minor release numbers.

Strictly normalized versioning makes packager's life _MUCH_ easier.

[zaytsev]

My friend, it's over :-) Now we comply with both Debian and RH/Fedora so I'm fine with this.

[ossi]

just to add some noise :P ... ​http://netrik.sourceforge.net//?versions.html

[andrew_b]

error in configure:

configure: line 2188: 0: command not found

Created 1905_versioning_fix branch. Parent branch is master.
changeset:52d4ad229d58dbb144fef2fc2b5cf3c404890142