Changes between Initial Version and Version 17 of Ticket #1905
- Timestamp:
- 01/06/10 17:26:17 (15 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #1905
- Property Status changed from new to reopened
- Property Severity changed from no branch to on review
- Property Cc weigelt@…, gotar@… added
- Property Version changed from master to 4.7.0.1
- Property Owner set to slavazanko
-
Ticket #1905 – Description
initial v17 1 1 We have a problem with the current mc-x.y.z-preW versioning scheme for both Redhat and Debian. The problem is that 2 3 2 (1) mc-1:4.7.0-1.fc12.x86_64 4 3 (2) mc-1:4.7.0.pre4.231.g8cfffc5-1.fc12.x86_64 5 6 4 (1) is considered to be older than (2) 7 8 5 This issue is discussed quite frequently on the net: 9 10 6 https://bugs.launchpad.net/openobject-client/+bug/314575 11 7 http://mail.python.org/pipermail/distutils-sig/2009-January/010678.html 12 13 8 etc. 14 15 16 9 {{{ 17 10 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. … … 21 14 Rpm Version: 5.0.0 22 15 Rpm Release: 0_rc2 23 24 16 Final release: 25 17 Upstream: foo-5.0.0 26 18 Rpm Version: 5.0.0 27 19 Rpm Release: 1 28 29 20 Now the final RPM release, 5.0.0-1, will update 5.0.0-0_rc2 30 21 }}} 31 32 22 My suggestion is to adopt the next scheme: 33 34 23 (1) mc-1:4.7.0-1.fc12.x86_64 35 24 (2) mc-1:4.7.0-0_pre4.231.g8cfffc5-1.fc12.x86_64 36 37 25 {{{ 38 26 Version: 4.7.0