id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	blockedby	blocking	branch_state	votes
1905	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}
}}}"	defect	new	major	4.7.1	mc-core	master