[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Summary: dpkg and alpha/beta versioning



Giuliano P Procida writes:
 > 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].


 > 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.

Problem: I don't think it is canonical that "beta" < "pre" wrt version
numbering.  I just hope no upstream maintainer will ever use both of
them for a particular version of a package, but who knows...

Hiding ~ is just a matter of presenting the real upstream number,
which will surely have no ~ in it.

 > 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)

Problem with it: you won't ever know how many steps will be necessary,
whereas you will now where to start from.

I'd say your proposal is interesting, but with a positive meaning for
numbers.  It will allow:

	1.0~pre
	1.0~1alpha
	1.0~1beta

With `~' followed by no numeric being seen as `~0'

 > ((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:

I must admit I don't see the need for that ;)

 > > * 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).

Well, maybe you're right.  Both mechanisms may be useful for different
purposes.

-- 
Yann Dirson    <ydirson@mygale.org> | Stop making M$-Bill richer & richer,
isp-email:   <ydirson@a2points.com> |     support Debian GNU/Linux:
debian-email:   <dirson@debian.org> |         more powerful, more stable !
http://www.mygale.org/~ydirson/     | Check <http://www.debian.org/>


--  
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: