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

Summary: dpkg and alpha/beta versioning


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

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

Con: we do not use upstream version number for *stable* versions.
This will confuse users.

* 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

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>

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


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,

	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>

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-dpkg-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: