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

Re: Package Versioning Feedback

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


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

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 >

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.

rpm will order this correctly. However, it is highly non-standard and will confuse a lot of people. (Just think about when you release 1.0.0 To the rest of the world this would signify a major milestone has been reached but for your project it would mean you're just getting started.) I would actually ask you not to do this as the world doesn't need another versioning scheme.

The use of a high number to denote a prerelease actually works well if you do it right. Look at this sequence, for instance:

1.0       <= stable
1.0.1     <= 1.0 bugfix
1.0.2     <= 1.0 bugfix2  <= alpha  <= alpha2  <= alpha3  <= beta  <= beta2  <= release candidate
1.1       <= final

This is easily read by both a human and a computer. As long as you don't have 90 bugfix releases between 1.0 and 1.1 you won't collide. (And you can either use a larger number .900, .950, .999 right off or add another dot and number if you find out too late:,, etc)


Attachment: signature.asc
Description: OpenPGP digital signature

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