Summary[2]: dpkg and alpha/beta versioning
Recent changes:
===============
* The 2.0.7-0pre1 scheme
* The <previous>.99.<whatever> example
* Comment by <gsstark@mit.edu> about epochs being bad
* The 2.0.7r example - comment about it being IMHO bad
* Jason's "Assigning meanings to words" scheme.
* Added my `~[0-9]*' extension to Gregory's `~'.
Context:
========
Several times already there have discussions about how to handle
alpha/beta version numbers. Several solutions using the existant
version-numbering scheme in `dpkg' have been offered by various
people, most of which do not apply to all possible cases, and none has
been selected. Other proposed solutions involved the extension of
dpkg's version-numbering scheme.
We should also consider that, while current packaging manual does not
mandate that version numbers be kept unchanged, it is highly desirable
that we follow it as closely as possible, to not confuse users (think
about someone looking at announcements in cola or freshmeat, and
expecting to find the new packages in Debian).
It currently says (section 5): "Usually this will be in the same
format as that specified by the upstream author(s); however, it may
need to be reformatted to fit into dpkg's format and comparison
scheme."
This is an attempt at describing all these proposed solution, with
pros and cons.
Proposals within existing version-numbering scheme:
===================================================
Pro: does not need to modify dpkg.
* use epochs.
Eg: 0:1.0beta << 1:1.0 << 1:2.0beta << 2:2.0
Example package: procps, bison
Pro: the package maintainer is always able to use the upstream numbers
as the debian upstream number.
Con: when an epoch is used once, it cannot be reverted. Although it
seems harmless as the epoch will probably never suffer from storage
overflow, some people seem not to like this solution very much.
Con: Essentially you are completely overriding the version number with
a hidden version number that the user isn't presented with. If we want
to go this route we could just abandon sorting on upstream package
version and number our releases sequentially. That may not be an
unreasonable way to go, but it certainly isn't the system we're using
now. <gsstark@mit.edu>
Con: against the current Packaging Manual's guidelines (section 5):
"Note that the purpose of epochs is to allow us to leave behind
mistakes in version numbering, and to cope with situations where the
version numbering changes. It is not there to cope with version
numbers containing strings of letters which dpkg cannot interpret
(such as ALPHA or pre-), or with silly orderings (the author of this
manual has heard of a package whose versions went 1.1, 1.2, 1.3, 1,
2.1, 2.2, 2 and so forth)."
Needed: Some technical info about why people consider epochs as bad.
It seems most arguments only used aesthetic reasons. Please someone
correct me if I'm wrong.
* use a new upstream-version component for alpha/whatever.
Eg. 2.0.7 => 2.0.7-1
=> 2.0.7-2
2.0.8pre1 => 2.0.8-0pre1
=> 2.0.8-1pre1
2.0.8 => 2.0.8-2
Example package: ??
Con: confuses Debian-release component and upstream one.
* use the upstream version string for alpha and beta releases, but
modify it to allow final release to sort correctly.
Eg: 1.60beta >> 1.60 => bad
1.60beta << 1.60final => OK
Example package: fweb
Eg: 2.0.7pre1 << 2.0.7r
Example package: libc6
Con: we do not use upstream version number for *stable* versions.
This will confuse users, especially with the "r" for "released" which
can even more easily be confused with an upstream pach-level.
* consider alpha/beta to be based on previous version.
Eg: 1.12-WIP >> 1.12 => bad
1.10 << 1.10-1.12-WIP << 1.12 => OK
Example package: e2fsprogs (1.10-1.12-WIP in experimental), krb4, fltk
Eg: 1.10 << 1.10.99.whatever << 1.11
Example package: ??
Pro: only modifies alpha/beta version-string, not stable one.
Con: still desync's the debian version from the upstream version: such
a 1.10-whatever can be seen by a user as an improvement on 1.10, which
it is not. This can be dangerous, it should be only used for
experimental dist IMHO.
* using the fact that '-' << '.'
Eg: 2.0-b1 << 2.0.0
Example package: maybe mpsql (was discussed on deb-dev)
Pro: can be used at no cost for some packages
Con: many packages will use 2.0-b1 then 2.0 upstream. This will need
to change the stable version number, possibly confusing users. And if
upstream issues a 2.0.0 version after 2.0 (can't see why, but I'm not
sure it never happened)
Proposals modifying current version-numbering scheme:
=====================================================
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>
* Generalized from Gregory's proposal, adding an optional numeric
argument to the `~':
Eg: 1.0pre => 1.0~pre
1.0alpha => 1.0~1alpha
1.0beta => 1.0~1beta
1.0 => 1.0
`~' followed by no numeric would be equivalent to `~0'. The main
other difference with Gregory's scheme is that the `~[0-9]*' string is
not printed in dselect list, instead of just `~'.
Submitter: Yann Dirson <ydirson@mygale.org> (inspired by Giuliano P
Procida's negative ~)
* 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").
Eg: 7.8.9pre4 << 1-3:7.8.9 << 7.8.10
Pro: non-persistent epoch for version sublevels
Con: - not really easy to read at such
- maybe too restrictive (correct me if I'm wrong):
1.0pre1 => 1.0pre1
1.0beta1 => 1-2:1.0beta1
1.0 => ???
- even Adam thinks Gregory's ~ idea is better ;)
Submitter: Adam P. Harris <apharris@burrito.onshore.com>
* Generalized from Adam's numbering scheme, another approach would be
to extend epochs in the following way:
"X1.X2...:A1.A2..." where each Xi refers to Ai.
This basically consists in associating an epoch with each component of
the upsream version number. This could be seen (and interpreted by
dpkg) somewhat like:
"(X1:A1).(X2:A2)..."
and the compare rule would be (in somewhat C-like pseudo code):
====
compare_greater_than (V1, V2)
{
for i in {1,2}
Wi = strchr (Vi, '.') + 1; /* strip 1st component */
return ((X1 >> X2) || ((A1 == A2) && compare_greater_than (W1,W2)) );
}
====
Adam's scheme can be seen as a special case of this one, where by
giving "X1-k:" you mean "Xk = 1", and "Xi = 0 for i not in {1,k}"
Pro: - non-persistent epoch for version sublevels
- not found a plausible numbering sequence that could not be
handled. Please help me to find one. Even the one given in
the packaging manual can be solved (somewhat of a hack,
though...):
1.1 => 1.1
1.2 => 1.2
1 => 0.1:1
Con: - not really easy to read at such
- maybe overkill
Submitter: Yann Dirson <ydirson@mygale.org>
* Assigning meanings to words.
Eg: 2.0.7alpha < 2.0.7beta < 2.0.7pre < 2.0.7
Pro: quite easy to understand
Con: there's no problem ordering `alpha' and `beta', but can we ensure
every upstream author using them will order `pre' or `wip' (I assume
it means `Work In Progress') relatively to `alpha' and `beta'. If
they do it differently than we do, we'll desync our numbering again.
Submitter: Jason Gunthorpe <jgg@gpu.srv.ualberta.ca>
--
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: