Package Versioning Feedback

[Toshio Kuratomi]

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

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
1.0.90.0  <= alpha
1.0.90.1  <= alpha2
1.0.90.2  <= alpha3
1.0.95.0  <= beta
1.0.95.1  <= beta2
1.0.99.0  <= 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: 1.0.89.1, 1.0.89.2, 
etc)

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080127/9cd03c61/attachment.sig>