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.0rc2That'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 <= finalThis 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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
