Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Rework the versioning scheme #1905

Closed
mc-butler opened this issue Dec 25, 2009 · 23 comments
Closed

Rework the versioning scheme #1905

mc-butler opened this issue Dec 25, 2009 · 23 comments
Assignees
@aborodin
Labels
area: core Issues not related to a specific subsystem prio: medium Has the potential to affect progress ver: 4.7.0.1 Reproducible in version 4.7.0.1
Milestone
4.7.1

Comments

@mc-butler
Copy link

Important

This issue was migrated from Trac:

Origin https://midnight-commander.org/ticket/1905
Reporter zaytsev (@zyv)
Mentions weigelt@….de, gotar@….pl

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

Original attachments:
@mc-butler
Copy link
Author

Changed by narcan (debian@…-briand.fr) on Dec 26, 2009 at 14:25 UTC (comment 1)

I confirm this issue on Debian.
thanks

Denis Briand
Debian maintainer

@mc-butler
Copy link
Author

Changed by zaytsev (@zyv) on Dec 27, 2009 at 16:00 UTC (comment 2)

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.

@mc-butler
Copy link
Author

Changed by slavazanko (@slavaz) on Dec 29, 2009 at 16:19 UTC (comment 3)

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

Created branch 1905_versioning_scheme

Initial [f8da5fe3ccbe6d10655189801fecf41bb1063ac5]

Review, please.

@mc-butler
Copy link
Author

Changed by andrew_b (@aborodin) on Dec 30, 2009 at 11:01 UTC (comment 4)

  • Votes set to andrew_b

@mc-butler
Copy link
Author

Changed by zaytsev (@zyv) on Dec 30, 2009 at 11:44 UTC (comment 5)

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?

@mc-butler
Copy link
Author

Changed by slavazanko (@slavaz) on Dec 30, 2009 at 11:53 UTC (comment 6)

See [1a0c1d700598202317de3eddae3d9758d572dba5]

@mc-butler
Copy link
Author

Changed by zaytsev (@zyv) on Dec 30, 2009 at 13:35 UTC

@mc-butler
Copy link
Author

Changed by slavazanko (@slavaz) on Dec 30, 2009 at 18:27 UTC (comment 7)

Branch rebased into one commit.

  • [e63ddb17d14b8023eda2b4b4c582020cae04e4a8]

Review, please.

@mc-butler
Copy link
Author

Changed by iNode (@iNode) on Dec 30, 2009 at 18:47 UTC (comment 8)

  • Votes changed from andrew_b to andrew_b iNode
  • Severity changed from on review to approved

@mc-butler
Copy link
Author

Changed by slavazanko (@slavaz) on Dec 30, 2009 at 18:52 UTC (comment 9)

  • Severity changed from approved to merged
  • Votes changed from andrew_b iNode to commited-master

Merge [24d9c60b1fadfe5681ed3334e6ae8ebfe0c01a77]

@mc-butler
Copy link
Author

Changed by slavazanko (@slavaz) on Dec 30, 2009 at 18:52 UTC (comment 10)

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

@mc-butler
Copy link
Author

Changed by slavazanko (@slavaz) on Dec 30, 2009 at 18:52 UTC (comment 11)

  • Status changed from testing to closed

@mc-butler
Copy link
Author

Changed by metux (@metux) on Dec 30, 2009 at 20:56 UTC (comment 12)

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.

@mc-butler
Copy link
Author

Changed by metux (@metux) on Dec 30, 2009 at 20:57 UTC (comment 13)

  • Cc set to weigelt@….de

@mc-butler
Copy link
Author

Changed by zaytsev (@zyv) on Dec 30, 2009 at 20:59 UTC (comment 14)

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

@mc-butler
Copy link
Author

Changed by gotar (gotar@….pl) on Dec 31, 2009 at 11:07 UTC (comment 15)

  • Cc changed from weigelt@….de to weigelt@….de, gotar@….pl

@mc-butler
Copy link
Author

Changed by ossi (@ossilator) on Dec 31, 2009 at 11:15 UTC (comment 16)

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

@mc-butler
Copy link
Author

Changed by andrew_b (@aborodin) on Jan 6, 2010 at 17:26 UTC (comment 17)

  • Votes commited-master deleted
  • Resolution fixed deleted
  • Version changed from master to 4.7.0.1
  • Description edited
  • Severity changed from merged to on review
  • Milestone changed from 4.7.0.1 to 4.7.1
  • Status changed from closed to reopened

error in configure:

configure: line 2188: 0: command not found

Created 1905_versioning_fix branch. Parent branch is master.
[52d4ad229d58dbb144fef2fc2b5cf3c404890142]

@mc-butler
Copy link
Author

Changed by slavazanko (@slavaz) on Jan 8, 2010 at 22:39 UTC (comment 18)

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

@mc-butler
Copy link
Author

Changed by slavazanko (@slavaz) on Jan 8, 2010 at 22:39 UTC (comment 19)

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

@mc-butler
Copy link
Author

Changed by iNode (@iNode) on Jan 11, 2010 at 5:10 UTC (comment 20)

  • Severity changed from on review to approved
  • Votes changed from slavazanko to slavazanko iNode

@mc-butler
Copy link
Author

Changed by andrew_b (@aborodin) on Jan 11, 2010 at 6:27 UTC (comment 21)

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

Merged to master.
[ec8bab2]

@mc-butler
Copy link
Author

Changed by slavazanko (@slavaz) on Jan 11, 2010 at 8:31 UTC (comment 22)

  • Status changed from testing to closed

Cherry-picked into 4.7.0-stable: [64d6ce1]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@aborodin aborodin

Labels
area: core Issues not related to a specific subsystem prio: medium Has the potential to affect progress ver: 4.7.0.1 Reproducible in version 4.7.0.1
Milestone
4.7.1
Development

No branches or pull requests
2 participants
@aborodin @mc-butler