Ticket #1905 (new defect) — at Initial Version
Rework the versioning scheme
Reported by: | zaytsev | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 4.7.1 |
Component: | mc-core | Version: | 4.7.0.1 |
Keywords: | Cc: | weigelt@…, gotar@… | |
Blocked By: | Blocking: | ||
Branch state: | Votes for changeset: |
Description
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}
Note: See
TracTickets for help on using
tickets.