Ticket #1905 (new defect) — at Initial Version

Opened 15 years ago

Last modified 15 years ago

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.