Package Versioning Feedback

[Michel Salim]

On Jan 26, 2008 6:01 PM, Richi Plana <myfedora at richip.dhs.org> wrote:
>
> On Sat, 2008-01-26 at 23:50 +0100, Michael Schwendt wrote:
> > On Sat, 26 Jan 2008 14:52:12 -0700, Richi Plana wrote:
> >
> > > Hi,
> > >
> > > I wanted to start my own little project and wanted some feedback from
> > > the community who've had much dealings with versioning. My plan is to
> > > use a versioning system similar to most (digits separated by a dot
> > > character) with each successive number being less significant. The only
> > > change in semantics is that the most minor number would be interpreted
> > > as
> > >
> > > 0 = Alpha
> > > 1 = Beta
> > > 3+ = Stable
> > >
> > > I thought this might be a better way of dealing with projects which
> > > transition to a greater major number. Systems which use .99+ to
> > > designate "almost next major" aren't easy to test as the next major
> > > version (since the computer parses the major version and sees the
> > > previous major version.
> > >
> > > Some systems increase the major and tack on the word "alpha" or
> > > "beta" ... which screws up the computer's sorting mechanism (is alpha >
> > > 0?)
> > >
> > > My question is: will there be any problems with packaging systems like
> > > rpm and yum using such a scheme?
> >
> > It depends on what your numbers look like. Preferably, use only natural
> > numbers (as they can be compared with each other in a well-defined way),
> > and don't make up your own notation for the numbers. In particular, never
> > use any numbers with 0 prefix, not in the least significant position
> > either. For RPM, 2 and 02 and 000002 are equal. Hence 1.1 is smaller than
> > 1.02, but equal to 1.01. And a 1.3001 release, which may look like a
> > very minor release after 1.3, would be higher than all 1.X with X < 3001,
> > including 1.4, 1.50, 1.99 and so on.
> >
> > As a side-note, adding non-numerical characters somewhere to a version
> > number string not only compares numbers to characters, it alters the
> > length of what is compared. Due to that, the longer version wins, as in
> > 1.3.0 is lower than 1.3.0a or 1.3.0rc2
>
> That's exactly why I'm interested in adopting the aforementioned
> semantic. And yes, I'll be sticking to decimal digits.
>
> For example, 1.3.0 is the alpha of the 1.3 series. 1.3.1 is the beta and
> 1.3.2, 1.3.3, etc. are the stable. That way if I wanted to bump it up to
> 1.4, for testers they'd be using 1.4.0 as alpha.

So basically Apple's numbering system for Leopard :) Sounds fine,
though you might want to make the version numbering system explicit
somewhere, otherwise packagers might mistake an alpha of yours as a
stable release.

I quite like the {alpha,beta,rc}n system as well -- it's not that hard
to tag the pre-release number in the release field, and it's more
obvious to a lay person what the state of the software is.

-- 
Michel Salim
http://hircus.jaiku.com/