Re: Summary: dpkg and alpha/beta versioning
Having just re-read the section in the packaging manual, I note that
dpkg does not chop version numbers by '.' but into non-numeric and
numeric components [/usr/doc/dpkg/packaging.html/ch-versions.html].
On 22 Jun 1998 Yann Dirson wrote:
> Proposals modifying current version-numbering scheme:
> =====================================================
My favourite was:
> Con: needs to modify dpkg...
>
> * Adding a new char (eg. '~') which would sort lower to anything, even
> the empty string.
>
> Eg: 2.0~b1 << 2.0
>
> Pro: this can be presented to the user with the ~ removed, thus
> showing the real upstream version string.
>
> Con: will have problems with the following release sequence:
>
> 1.0pre1 => 1.0~pre1
> 1.0beta1 => ???
> 1.0 => 1.0
>
> although, if it known in advance that there will be "beta" following
> "pre", we can use:
>
> 1.0pre1 => 1.0~~pre1
> 1.0beta1 => 1.0~beta1
> 1.0 => 1.0
>
> Submitter: Gregory S. Stark <gsstark@mit.edu>
I would have thought that alpha < beta < gamma < pre (< rel) order
nicely by themselves and if this is true in practice then you don't
need the ~~ trick. I also don't see any need to hide ~ from the admin.
Here is my suggestion (has it been put forward before?):
A (logical?) alternative is to have ~ (or whatever) be "negation":
~n meaning (-n) (n is [0-9]\+)
~ aliased to (-1) (or -0? -1/2?) (~ not followed by numeral)
It starts a new numerical component wherever it appears. This gives:
1.0~alpha1
1.0~beta1
which is just the same as Gregory's suggestion, but has an extra Pro
for those people who like negative numbers in their version strings:
1.0~2 (alpha test)
1.0~1 (beta test)
1.0 (release)
((Alternative alternative: someone might want to order: 1.-c, 1.-b,
1.-a, 1, 1.a, 1.b, 1.c in which case "~" would also negate
non-numerical components and you would need:
1.0~.alpha1
1.0~.beta1
to get the right ordering.))
> * Using epoch subversions, with "1-3:7.8.9" meaning the epoch only
> overrides the 3rd point-level of the version (the "9" in "1-3:7.8.9").
> * Generalized from Adam's numbering scheme, another approach would be
> to extend epochs [snip]
IMHO, epochs are really only needed to deal with mistakes in
versioning and it is probably worth extending them so that they can
apply to subcomponents (the advantage here is that a subepoch reflects
more accurately the versioning problem and, as soon as a more major
version change occurs, the subepoch can be discarded).
Epochs help after versioning breakage. Negative components would help
before in the alpha/beta cases.
Giuliano Procida.
--
mail: gpp10@cam.ac.uk / myxie@debian.org | public PGP key ID: 93898735
home: +44 1223 561237 / 547 Newmarket Road, Cambridge CB5 8PA, UK
work: +44 1223 332127 / Magdalene College, Cambridge CB3 0AG, UK
work: +44 1223 335333 / International Studies, Cambridge CB2 1QY, UK
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: