Package Versioning Feedback
Toshio Kuratomi
a.badger at gmail.com
Sun Jan 27 16:16:09 UTC 2008
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://lists.fedoraproject.org/pipermail/devel/attachments/20080127/9cd03c61/attachment-0002.bin
More information about the devel
mailing list