Ticket #1905 (closed defect: fixed)

Opened 7 years ago

Last modified 6 years ago

Rework the versioning scheme

Reported by: zaytsev Owned by: andrew_b
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: committed-master

Description (last modified by andrew_b) (diff)

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}

Attachments

mc-versions.pdf (53.0 KB) - added by zaytsev 7 years ago.

Change History

comment:1 Changed 7 years ago by narcan

I confirm this issue on Debian.
thanks

Denis Briand
Debian maintainer

comment:2 Changed 7 years ago by zaytsev

http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_packages

alsa-lib-0.9.2-0.1.beta1 (add a new patch on top of 0.9.2beta1)
alsa-lib-0.9.2-0.2.beta1 (upgrade to 0.9.2beta2)
alsa-lib-0.9.2-0.3.beta2 (upgrade to 0.9.2beta3)
alsa-lib-0.9.2-0.4.beta3 (add a new patch on top of 0.9.2beta3)
alsa-lib-0.9.2-0.5.beta3 (upgrade to 0.9.2rc1)
alsa-lib-0.9.2-0.6.rc1 (upgrade to 0.9.2rc2)
alsa-lib-0.9.2-0.7.rc2 (upgrade to 0.9.2 "final", version becomes normal)
alsa-lib-0.9.2-1 (add a new patch on top of 0.9.2 "final")
alsa-lib-0.9.2-2

Translates to:

mc-4.7.0-0.1.1.pre1
mc-4.7.0-0.1.2.pre1.gittag1
mc-4.7.0-0.1.3.pre1.gittag2
mc-4.7.0-0.1.4.pre1.gittag3
...
mc-4.7.0-0.1.128.pre1.gittag128
mc-4.7.0-0.2.1.pre2
...
mc-4.7.0-0.3.1.pre3
mc-4.7.0-0.4.1.pre4
...
mc-4.7.0-1

And everything will be fine.

We need an autotools expert.

comment:3 Changed 7 years ago by slavazanko

  • Owner set to slavazanko
  • Status changed from new to accepted
  • severity changed from no branch to on review
  • Milestone changed from 4.7.1 to 4.7.0.1

Created branch 1905_versioning_scheme

Initial changeset:f8da5fe3ccbe6d10655189801fecf41bb1063ac5

Review, please.

comment:4 Changed 7 years ago by andrew_b

  • Votes for changeset set to andrew_b

comment:5 Changed 7 years ago by zaytsev

Why would be just comply to Fedora Packaging Guidelines as I commented above? I discovered them after doing more research on the ticket, that's why I didn't update the description. That's not too hard, Slava, could you please tweak your branch accordingly?

Changed 7 years ago by zaytsev

comment:7 Changed 7 years ago by slavazanko

Branch rebased into one commit.

Review, please.

comment:8 Changed 7 years ago by iNode

  • Votes for changeset changed from andrew_b to andrew_b iNode
  • severity changed from on review to approved

comment:9 Changed 7 years ago by slavazanko

  • Votes for changeset changed from andrew_b iNode to commited-master
  • severity changed from approved to merged

comment:10 Changed 7 years ago by slavazanko

  • Status changed from accepted to testing
  • Resolution set to fixed

comment:11 Changed 7 years ago by slavazanko

  • Status changed from testing to closed

comment:12 Changed 7 years ago by metux

Some general notes (not just to mc):

Version numbers should _always_ be an hierachic vector,
meaning [a,b+1,c,d] >> [a,b,c,d], etc.

Mathematically speaking: V=[a,b,c,d] <=> V*=(a*k3)+(b*k2)+(c*k1)+(d*k0).
(actually, that's how my Briegel build/packaging system, as well as OSS-QM, handles version numbers).

Upstream should only use the a,b,c elements and having d=0, leaving it to distro-internal revision.

We shouldnt do prereleases at all, betatesting should happen either directly on master or separate tags in their own namespace, or maybe deviding into odd/even minor release numbers.

Strictly normalized versioning makes packager's life _MUCH_ easier.

comment:13 Changed 7 years ago by metux

  • Cc weigelt@… added

comment:14 Changed 7 years ago by zaytsev

My friend, it's over :-) Now we comply with both Debian and RH/Fedora so I'm fine with this.

comment:15 Changed 7 years ago by gotar

  • Cc gotar@… added

comment:16 Changed 7 years ago by ossi

just to add some noise :P ... http://netrik.sourceforge.net//?versions.html

comment:17 Changed 7 years ago by andrew_b

  • Status changed from closed to reopened
  • Votes for changeset commited-master deleted
  • severity changed from merged to on review
  • Version changed from master to 4.7.0.1
  • Milestone changed from 4.7.0.1 to 4.7.1
  • Resolution fixed deleted
  • Description modified (diff)

error in configure:

configure: line 2188: 0: command not found

Created 1905_versioning_fix branch. Parent branch is master.
changeset:52d4ad229d58dbb144fef2fc2b5cf3c404890142

comment:18 Changed 7 years ago by slavazanko

  • Status changed from reopened to accepted
  • Votes for changeset set to slavazanko

comment:19 Changed 7 years ago by slavazanko

  • Status changed from accepted to assigned
  • Owner changed from slavazanko to andrew_b

comment:20 Changed 7 years ago by iNode

  • Votes for changeset changed from slavazanko to slavazanko iNode
  • severity changed from on review to approved

comment:21 Changed 7 years ago by andrew_b

  • Status changed from assigned to testing
  • Votes for changeset changed from slavazanko iNode to commited-master
  • Resolution set to fixed
  • severity changed from approved to merged

comment:22 Changed 7 years ago by slavazanko

  • Status changed from testing to closed

Cherry-picked into 4.7.0-stable: 64d6ce1fa014a60fd0f9d9187decbcaa01cbcfde

Note: See TracTickets for help on using tickets.