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	andrew_b	"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	closed	major	4.7.1	mc-core	4.7.0.1	fixed		weigelt@… gotar@…				committed-master