This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new!


Decline and fall of the version number

By Nathan Willis on June 11, 2005 (8:00:00 AM)

Share    Print    Comments   

As a software version-numbering aficionado, I have recently concluded that the FOSS world has gone mad and is hurling itself -- users and developers alike -- into a black hole of confusion and long-winded explanations.

This realization first struck me weeks ago while I was reading a thorough review of GCC 4.0 by Scott Robert Ladd. The review itself was precise, documented, and well-thought-out. I liked it. But it concluded with this harrowing assessment:

<nobr> <wbr></nobr>... no one should expect a "point-oh-point-oh" release to deliver the full potential of a product, particularly when it comes to a software system with the complexity of GCC.

Yikes. Historically the point-oh release signified a finished product. That was why release teams resorted to tacking on Greek letter suffixes and precious metal monikers as caveats while they sweated swatting those final few bugs. When did all that change? I wondered. Is it a point-oh release whether it's ready or not?

Then I remembered the Linux kernel. When I first starting running Linux, the venerated odd/even dual-branch numbering scheme was The Law: 2.1 for development, 2.0 for general consumption. That's gone, too. Before 2.6.0 was unleashed, we witnessed a parade of "pre"-this and "pre"-that-"testX" kernels before the ball dropped.

And since then there hasn't even been and odd-numbered kernel series. Development takes places in branches maintained by individual branch maintainers, a change that has two important effects. First off, it has ruined the formerly crisp-looking homepage at Whereas in the past two links were sufficient to completely describe the state of the kernel, it now takes 11 kernels and four pages of definitions. But FAQs and wikis still advertise the odd/even scheme, several years out of date.

Secondly, Linux enthusiasts live in fear now; fear that any day (perhaps today) a non-Linux programmer you know is going to walk up to you at a street corner and ask, "When is there going to be a new version of Linux again?" Your first instinct will be to blurt out, "Well, you see, odd-numbered kernels are the unstable series where they do the development, even-numbered kernels are the stable branch. Cheers." But you'll be wrong, and will have to either launch into a long and drawn-out explanation of the BitKeeper fiasco or quickly concoct a web of lies.

Reflecting on this I lamented also the countless man-hours GNOME developers spend explaining that to them 2.10 comes after 2.8, the mistrust on the faces of Ubuntu neophytes upon hearing that Ubuntu 5.04 is a finished "point-oh" release, and the headaches brought on by debating whether to install WINE 20041019 or WINE 20050111. Then, just when I thought it could get no worse, the Anjuta IDE project simultaneously announced a stable release numbered 1.2.3 and a development release numbered 2.0.0. We had finally come full-circle.

All of the laws of version numbering are now but charred ashes; not only was this x.0.0 release not to be blindly trusted without skepticism, it wasn't even meant to be run by users at all.

So what?

Of course, I am using a fair bit of false naivete in describing these incidents; I'm familiar with all of the aforementioned projects and I am not really confused by their version numbers. But I am able to navigate between the incompatible meanings of those numbers only because of my personal familiarity with the projects over the course of time. A new user would be genuinely confused.

That confusion illustrates how a non-technical decision as unsubstantial as the number tacked on after a release can have unintended and unfortunate side effects. Picking a bizarre or unpleasant project name can distance new users. Making a major release the same day the new Xbox hits the shelves can cost press coverage. Abandoning your established version-numbering scheme can call down a scourge of mail messages all asking the same questions over and over again.

The big question is whether or not open source is more vulnerable to this type of malady than closed-source, commercial vendors. I'm going to take the foolhardy step of openly soliciting comments on that question.

My gut feeling is that open projects are susceptible to these kind of non-technical pitfalls, precisely because they are founded and driven by technical thinkers and workers. As hard as it is to attract coders to your project, it is far harder to get volunteers for the non-technical tasks (bug triage, documentation, aesthetic stuff) just because the community (by definition) is populated with programmers. In contrast, commercial products are cooked up by front-office suits, marketing surveys, and knee-jerk reaction to popular trends, then non-technical decisions (and, regrettably, technical ones) are made by non-techies -- up to and including the name of the product and its release schedule.

But there is evidence to the contrary as well. Namely, the change in kernel version numbering seems correlated to corporate support of its development. The demise of the odd-numbered development branch was most publicly associated with Linus's adoption of BitKeeper, but the numbering change actually began earlier. Specifically, the more corporate capital has been funding kernel development and paying salaried developers, the more -testX and pre-releases have preceded each new x.0.0 release.

That in itself makes sense; given that closed source vendors have the luxury of not inadvertently selling a beta-status product, no open source vendor wants to jump the gun and ship its package with a critical bug. Thus they squeeze extra QA cycles out of the development team, that we see in the form of those pre- and -testX releases.

Based on some Googling, it also seems that commercial Linux distributions have become slower and slower to adopt x.0.0 kernels in their boxed-and-shelved products. This is, of course, at odds with the extended test cycle that produces each x.0.0 release -- if you take longer testing it, you should be more certain of it once it is ready.

Fight the man?

So, corporate interference is screwing up the release-numbering of the Linux kernel? Possibly. But it's the ripple effect of this interference on those unguarded, non-technical factors of other open source projects that bothers me.

I've already said that conflicting numbering schemes lead to confusion for the user; now you have to have firsthand experience with a software project in order to interpret its new releases. Version numbering is the one thing that distinguishes one release of an application or library from another. If people are confused by it or it generates more support forum questions than your actual software, you have a problem.

Luckily, I am here to present to you what I'm humbly calling Willis's Three Laws of Release Numerics. Adhere to these rules and happy users, accolades, and peer respect will beat a path to your door.

The First Law: Pick a numbering scheme, then don't change it. Ever. When you get right down to it, the only purpose a version number serves is to denote the relative supremacy of one of those versions compared to another. That's why even though commercial software vendors periodically decide to rename their products with letters (see RealPlayer G2 for a historical example, or Adobe's Photoshop CS for a will-be-a-historical-example-shortly example), they always have to slink back to the good old real number system when their customer service reaches the 90% threshold on that one question.

This doesn't mean that you can't decide that your big rewrite merits a major-number increment instead of a minor-number increment. But it does mean don't switch from the venerated even/odd scheme to an odd/even scheme or to a new scheme tied directly to the numbering scheme of some toolkit you depend on. Don't make a point-oh release mean "unstable" when the previous point-oh release meant "stable."

The Second Law: Don't mess with math. In other words, don't employ a scheme that violates established rules of numbers. Higher numbers indicate more recent versions. Numbers sort; your FTP archive needs to sort in some meaningful way, or you are asking for a world of hurt. Tacking on -testX, -alpha, or -beta will give you releases that may or may not sort correctly, so avoid them.

Furthermore: if you use decimal points as your major/minor delimiter, your users are going to ask you why<nobr> <wbr></nobr>.10 comes after<nobr> <wbr></nobr>.8, every single time. And the misunderstanding is not their fault, it is yours; the decimal point has a very precise meaning and has had for 400 years. You've chosen to overload it by declaring that in this one special context, it means something different. John Napier invented it in 1619; lacking his permission, don't try to assign new definitions and behavior to it.

Brrr. I can feel the "it's not a decimal point" police straightening up the chips on their shoulders and reaching for their email clients. Nevertheless, we trudge on. Your choices are: (a) get comfortable with re-explaining your decision every time, (b) increment from 2.8 to 3.0 as OpenBSD does so effortlessly, or (c) pick one of the plentiful other ASCII characters as a delimiter. There's no shortage.

The Third Law: Make friends with infinity. In other words, don't be afraid to increment. You're not going to run out of numbers; we have mathematicians working around the clock to find new and bigger ones for common usage all the time. Trepidation to increment version numbers leads programmers to commit heinous sins like tacking on additional ".minor.minor" decimals to subsequent releases, leading to a syndrome called decimal bloat wherein the version number changes more and more slowly approaching some finite limit, but the length of the version number increases without bound. The logical end of this behavior is a program whose version number consumes all of the system resources and thus cannot be run.

In the real world, though, remember that Sun famously decided to leap forward from Solaris 2.6 to Solaris 7 when it realized that everyone else in the software industry was incrementing their numbers faster, and they suddenly looked like they had lots of ground to catch up. I have seen a lot of open source projects fall victim to the same "is this different enough to increment the minor number?" paralysis. It doesn't matter if there are fewer changes between 2.4 and 2.6 than there were between 2.2 and 2.4. All that matters is that the number communicates which one is the most recent. Decelerating release numbers make outsiders think that development has slowed, and that misconception will hurt your user base.

A brave new tomorrow?

The world used to make sense. As the first rays of dawn broke over the horizon, farmers strode nobly into their fields of grain to reap the harvest of an honest season's living, while across the country programmers put to rest another night's coding and packaged a well-honed x.0 release, wistfully watching it bound off into the Internet to replicate blissfully on the mirror servers. People everywhere were happy.

Then our version numbers collapsed. There was chaos. Some numbers got longer and longer. Some turned into letters and words. Some became dates. Nobody knew what the numbers meant anymore. People were afraid to ask what the numbers meant, and they became afraid of numbers themselves.

What happens next remains to be seen. Will there be riots in the streets? Blockades? Protesters spray-painting numbers on the walls of company headquarters? No. How about the gradual awakening of an enlightened, numerically harmonious world consciousness? I wouldn't bet on that either. But maybe a generation from now, when those post-apocalyptic programmers rebuild the software industry from its ashes, they'll do it right from the ground up. Here's to you, amigos.

Share    Print    Comments   


on Decline and fall of the version number

Note: Comments are owned by the poster. We are not responsible for their content.

version numbers are for experts only

Posted by: Anonymous Coward on June 11, 2005 06:32 PM
I doubt that the exact version number of a program/library is of serious issue for a common desktop user.

However as soon as someone gets into development she can ask her way through.

What I dislike most are projects that make no releases at all but expect their users to check out from CVS/SVN itself.

Btw: IMHO version numbers are just labels (a shallow outwards appearance), what an app/library is really capable of doing can only experienced by using it. I believe in the hacker ethics, which teaches to not value someone by his or her outward appearance<nobr> <wbr></nobr>...


Re:version numbers are for experts only

Posted by: Anonymous Coward on June 12, 2005 02:44 AM
It doesn't matter until you tell normal users they need version X.Y.Z to run your software. Or someone else depends on your software and needs to tell their users what release to use.

Then normal users have to figure out: Is the version I have compatible? New enough? If I upgrade a dependency will it break?

Version numbers matter in the same way that knowing what inputs your TV has before buying your new VCR. It matters in the same way as knowing what the make and model of your car is before you buy an oil filter.


Very interesting article.

Posted by: Anonymous Coward on June 11, 2005 06:34 PM
Thank you for your effort.


Missed the best example...

Posted by: Anonymous Coward on June 11, 2005 06:35 PM
And you didn't even meantion the best example! TeX's version number <a href="" title="">limits to pi</a>

Of course, the fact that it is primarily used by mathematicians may have something to do with that...


Re:Missed the best example...

Posted by: hazza on June 13, 2005 09:42 PM
I am not familiar with Tex but why is Java 5 Release 2 called 1.5.2? Or is it the other way around? See Even I am confused.


Re:Missed the best example...

Posted by: Anonymous Coward on June 16, 2005 12:37 AM
I think this is meant to express the idea that TeX isn't evolving anymore -- just slowly "converging" to bug-free status.
And, by the way, Metafont's version number limits to e.


You are right - and it matters

Posted by: hopethishelps on June 11, 2005 07:22 PM

I hope Linus et al read this article and think about the mess they are creating.

One of the best articles on Newsforge lately. Well-written, too.


Versioning is also an open source endeavor

Posted by: Anonymous Coward on June 16, 2005 10:39 AM
Anyway, the typical user has little care or business compiling kernels. On the other hand, if the kernel maintainers were all complaining to Linus, that would be different.

In other words, why should the criticisms of those that don't compile kernels be taken to be more important than (or even as equally important as) the acceptances of those that do.

Surely, we all aim to please whenever possible. We all like ideas and opinions that could save our necks to be tossed around. But that doesn't mean much is going to happen just because someone thinks they know what is best for the rest.

If you are a developer, state so, I guess.

If you aren't, complain to maybe Xandros or Mandriva or someone else since it is likely to have a greater impact on and importance to them.


Re:Versioning is also an open source endeavor

Posted by: Anonymous Coward on June 16, 2005 10:57 AM
Let me add:

I did not mean to be issulting, but if versioning is a skill, then:
-- let those that are skillful at it and want to contribute do so,
-- so too is versioning WHILE developing, coordinating, etc FOSS.

For the first case, you can contribute by, eg, taking all of the kernels and reorganizing them. Either do this only with past kernels (as an exercise/ proof of concept/ to get caught up for at least a little while), or commit to doing this for at least some time into the future.

For the second case, I'd say that maybe Linus has a little more experience than most. It isn't easy to brainstorm, study, develop, accept patches, return emails, coordinate, keep everyone upto date with newest kernels, and have a versioning system that can explain to other developers the various existing/subtle/not-so-subtle differences at a glance so that they are saved lots of headaches and do not become discouraged from contributing (for those that keep up with AND all the while be going throught the BitKEEPER thing.

[For the most part, "you" means "someone."]

On the other hand, maybe not enough people want to complain to Linus? Maybe it is easier on this forum than on a kernel mailing list? Maybe no one wants to rock the boat?


Fun Stuff

Posted by: Anonymous Coward on June 11, 2005 07:25 PM
Great article! Very well written! Who thought an article about version numbering could be funny!


Thank you, Less

Posted by: Anonymous Coward on June 11, 2005 09:33 PM
Less did away with the dot! They are currently on version 382.


Re:Thank you, Less

Posted by: Anonymous Coward on June 11, 2005 10:14 PM
I guess this proves less is more.<nobr> <wbr></nobr>:-)


Re:Thank you, Less

Posted by: Anonymous Coward on June 12, 2005 04:11 AM
150657 -r-xr-xr-x 3 root wheel 117893 Mar 23 00:07<nobr> <wbr></nobr>/usr/bin/less
150657 -r-xr-xr-x 3 root wheel 117893 Mar 23 00:07<nobr> <wbr></nobr>/usr/bin/more


Numbering and Naming In General

Posted by: Anonymous Coward on June 11, 2005 11:13 PM
Nice piece. It puts me in mind of other long standing numbering and naming frustrations end users must contend with generally.
Why aren't the number of digits within an unbroken string of numbers considered when files are ordered in a file browser? Example:

Should Be:

In order for a user to be able to maintain an ordered list of numbered files they must pre guess the future maximum they will have. If they are reasonably sure the number will not exceed 99, they must start the first at 01. If they guess wrong and reach 100, then all the other 99 must be re-named starting with 001 and so on. This is a fundamental problem which compounds the issues you relate to in this article. Why not fix these obvious problems that affect each and every computer "end user" too.

Often times, because dated materials such as files of audio programs are not named using the year-month-day format, these files also get out of order. And because of the numbering problem mentioned above, the months and days must use the 01,02, format.

How many bookmarks do you have that would be named "Welcome" if you didn't change it. The Linux Show was a perfect example of this stupidity on the part of webmasters. Their bookmark defaulted to The Original Weekly Open Source/GNU/Linux/News Show. Or some such nonsense that makes their website bookmark hard to find. Because people instinctively look for "The Linux Show".

When I came over to Linux,I was quite surprised these kind of things were not addressed.


Re:Numbering and Naming In General

Posted by: Anonymous Coward on June 12, 2005 04:59 AM
Yes, digit numbering is an irritation because computers are still too stupid to distinguish between a digit as text and a text digit used as a sequential number. Only conceptual processing will change this nonsense.

I have over 250,000 babe pictures on my hard drive. I usually number them sequentially (within particular babe) and thus have to guess whether this babe will ever have more than 99 or more than 999 pictures. Sometimes I guess wrong - Keira Knightly is rapidly approaching a thousand even after only being a celebrity for the last two years. I could of course assume ALL of them could hit 9999 and use three leading zeros, but that really looks dumb when you have only 20 pictures of somebody new.

So I use a powerful file renaming program to renumber everything when I'm wrong.

Audio media programs that deign to assume how you are naming your MP3's irritate me, too. It took me a while to figure out how to get Winamp's media library to use MY filename instead of their parsing of it.


Ohhhhh, I Get It Now! Buffin The Badger, "Babes"!

Posted by: Anonymous Coward on June 12, 2005 08:05 AM
When you said you had 250,000 babe pictures, I thought you might be a baby (child) photographer and were using some kind of industry slang (babe). I thought Keira Knightly might be a child star on some sitcom or something. I don't watch commercial TV (over 10 years) so I wouldn't know of such things. So, I did a Google search of Keira Knightly. Your talking about "the lights out with your Y fronts around your ankles kind of Babes". O.K. I get it now. 250,000 of them ? Must be hell keeping stocked up on Kleenex.


Re:Numbering and Naming In General

Posted by: Anonymous Coward on June 13, 2005 12:19 AM
Try your numbering sequence as a series of file names under windows. I had someone give me a series of pictures which they had assembled under windows XP with a numbering scheme similer to what you have given. She asked me why they wouldn't stay in the order she wanted them. Basically, windows is just a dumb as linux when it comes to sorting file names. The answer was that she had to insert leading zeros in the number in order to make the file system utilities sort them correctly.

Here are some issues with what you are suggesting. Should 1 + 1 equal 2 or 11? Should 3 * 3 = 9 or should it equal 333? Should 8/4 = 2 or should it be an error? Is 2004-12-17 a date or a mathamatical formula? Lets re-do that as 2004/12/17. How can you tell whether that is a date or if it is a mathamatical sequence? Who knows, maybe it is a file name string and specifies file "17" in folder "12" which is in folder "2004". Any time you try to make a computer guess at the meaning of a data item you are trying to make it read someones mind. It is true that you can come close a lot of times ---- IF you know the context. However, there will always be times when you get it wrong. If the computer does the guessing, then it can be very difficult to get the machine to do what you intended instead of what it thought you intended. As an asside, this is my major complaint about MS Windows and its management philosophy.

You may want to have a look at the IBM iSeries(AS/400 or i5 -- so yes, IBM has gone name crazy too) or something similer. In that environment, you allocate a certain number of digits for a number, and then everything always lines up correctly. Also, in the more recent versions, dates are stored internally as YYYYMMDDHHMMSS and thus always sort correctly reguardless of the formatting given for the display of those dates. With OS/400 and the numbering sequence you listed, I would define the numbers as being, say 9 or 15 digits in length. Then I would define the display of those numbers to be with leading zero suppression and left aligned. They would come out listed in the order you said they should. Because the data items are type identified, a date can be specified as 12-17-2004, Dec, 17 2004, 2004/12/17 or 17 Dec 2004 and all be recognized correctly. But the data type is known, so the user can enter the date in almost any form he/she wants and the computer can recognize it. In other words, data types create a context that the computer can use to interpret what various data items mean. It can then use that context information to present that data back to us in a reasonable way. For example, some of us are used to seeing our dates as Jan. 3, 2001, and others of us are used to seeing them as 3 Jan, 2001. If the computer knows the data type, then it can adjust the display to our preference. If it doesn't know the data type, how can it help us? This is one of the goals of the Reiser 4 file system. OS/400 allows this kind of data type information to be applied to the contents of its files. From what I can tell Reiser 4 will also allow the same type of information to be applied to the file names if you wish. I know that it has been a unixish trait to have the file system store data, and let the applications interpret that data as they see fit. It is also unixish to have scripting languages push that data type definition out to the run time. This has the effect of making the user decide what the data type will be, and the programmer then has to guess what the user will think. It just seems to me that OS/400 and the Reiser 4 file system have gone in the right direction in explicitly telling the computer what the context is for each piece of data, and then let it translate what the user said within that context.


Re:Numbering and Naming In General

Posted by: Anonymous Coward on June 13, 2005 11:32 PM
Because most file managers sort the display alphabetically.

Just like you would not expect a word beginning with the letter B to appear in the middle of a list of words starting with the letter A.

So because of this you get something like:



Re:Numbering and Naming In General

Posted by: Anonymous Coward on June 18, 2005 06:12 AM
But you're all missing the point. Computers are certainly smart enough to do a natural sort (<a href="" title=""></a>). I guess it doesn't solve the "problem" of 4/5 in a filename, but it works good enough for almost all humans to understand almost all the time. It's not too hard to implement either.


To Whomsoever It May Concern

Posted by: Anonymous Coward on June 11, 2005 11:23 PM
The libtool/ld uses a version number system:


the first two are pretty self explanatory, the age bit need examples to explain.

first of all, interface - age > 0 demonstrates backwards compatibility. So a lib like


supports interfaces

<tt>3, 2 and 1</tt>

but NOT interface zero. A lib like


supports interfaces

<tt>7, 6 and 5</tt>

and so on<nobr> <wbr></nobr>...

the idea is that if you are using something libfoo 3.4.0 in your code a lot and see the version bump up to 3.5.0 you will know that only the implementation, not the interface, to the code has changed and can upgrade with some confidence. if, however, you saw the version go from 3.4.0 to 4.0.1 you know that the interface has changed and you should upgrade with caution. an interface change might be something major like changing a method signature or name, or it could be something minor like adding a new method (but all odds
one stay the same) - in either case the version gives you certain hints.

That said, why don't other developers follow such schemes?

Shouldn't there be an RFC on version numbers too?

I would love to see, some coherence in version numbers at least for F/LOSS<nobr> <wbr></nobr>:)




Posted by: Prototerm on June 12, 2005 07:33 AM
Sorry, but that's just absurd, and makes the ".10" controversy seem obvious by comparison. Programs should be written as simple as possible (and no more). I don't know how many times I've found myself patching a "gee, look what I can do" routine that is more complex than it needs to be. Many times, I've been forced to resort to a "gut and paste" to get the fix done by the deadline, rather than repair the twisted logic. The danger in using a complex scheme such as the one you suggest is that, sooner or later, someone will make a mistake, either in interpreting an existing version number, or in creating one for a new program.

Besides, that information doesn't belong in a version number, it belongs in the program's documentation (Functional specs, technical specs, and/or user docs). Keeping things simple and obvious saves time as well as misery.



Posted by: Anonymous Coward on June 14, 2005 03:37 PM
>> Besides, that information doesn't belong in a version number, it belongs in the program's documentation (Functional specs, technical specs, and/or user docs).

Well, the intent is, I believe, that this scheme allows certain correct automations to take place with some tools. I am not in love with the scheme, but many other ways of labeling versions, while they look nice and convey some simple concept to most users, do not convey all the required info to allow certain types of automation (that are carried out guided by the file name or by some binary format info or other and not by "technical specs" or by "user docs").

Who says we can't have an external and an internal (or >2) versioning schemes? Or for that matter, metadata that can be added in various places to convey various meanings.

An earlier poster wrote at length about the Reiser filesystem (and OS/400 and others). My informed guess is that Reiser allows a lot more information about a file to be held outside the file (in filesystem domain). In this case, you could solve many of these problems by simply having as many attributes as necessary to hold as much info as was required/wanted. In such a scenario, it would be easier to have display tools, search tools, viewers, etc, of the filesystem come in more flavors that were to the liking of more people. In all cases, files may appear, sort, etc, differently to different people but each would still have the same files and be able to get the same milage out of them.

EG, I could display on my files-viewer nice short names when viewing some directory (or as the result of some query). In the case of apparently multiple files with the same name (eg, 2 libraries under<nobr> <wbr></nobr>/usr/lib that are missing the typical version extensions, or 2 files named the same but recognized as different to the system, differing in other (invisible) metadata), my viewer would be set up so that hovering the mouse over the file would show some customized amount of the metadata<nobr> <wbr></nobr>... for example: the "." extension, the author, the size, the version, the lib or distro or app or desktop compatibility code, the upgrade url, the origin package url, the last modification author or user or app or process, an alternative icon (or music/3d-pic/video-clip) selection list, last action, suggested actions, last 10 sentences/characters in the file, the programming language or file class, file-project homepage, previous personal notes about the file, etc. --- all of these things would of course need to be standardized to some extent. Standardization of various info about files is what seems to be in short. [someone else also posted about having an internet RFC for versioning... similar spirit as here.]

A lot of libraries programmers use allow searching uniquely for a file based solely on the name (considering the parent hierchy of directories to be part of the name). This would have to be revamped somehow if we were going to de-emphasize the overloading of file names (in order to convey quick-and-dirty file metadata.. for searching, sorting, categorizing, etc) and insist that all the "invisible" metadata be parameterized in standard system function calls. Certainly, this *may* complicate the application interface to the filesystem. Likewise programmers would have to change long-established habits. [the reiser post mentioned earlier also indicates that this meta-info is currently found within files (eg, config files); however, as a shortcut, the actual filename is often overloaded with meanings.]

Note too that developers prefer to be most efficient at developing what they have chosen to do. They are scraching their itch and versioning is not always high priority, especially if they have to reinvent the wheel and there is no standard. Also, there are many surprises the crop up in software development in general. Apparently, versioning hasn't been standardized and "taught" for one reason or another. To deal with the unexpected, sometimes the versioning scheme chosen is what gets versioned.


Re:To Whomsoever It May Concern

Posted by: Anonymous Coward on June 16, 2005 12:22 PM
That idea strikes me as very clever. It assumes that you know that's how the version number works, but - as you point out - takes out a LOT of guess-work about what exactly has changed, and whether it is compatible with earlier versions.

Of course, the documentation is the place to go into detail about what has changed, but I for one would prefer to be able to just glance through the version numbers on SourceForge or whatever and take a punt on that - without downloading all the documentation and wading through that too. This is especially true if I just want to fulfil a dependency for something else I want to get working. The less reading and shyte I have to do for each link in the chain, the better.


Great article

Posted by: Anonymous Coward on June 12, 2005 12:20 AM
Great article. That's one of the reasons why I'm sticking with 2.4.30<nobr> <wbr></nobr>:)


Re:Great article

Posted by: Anonymous Coward on June 13, 2005 03:04 AM
But you're already behind. 2.4.31 is already out.<nobr> <wbr></nobr>;-)


You mean like..

Posted by: alandd on June 12, 2005 02:52 AM
Windows 3.0 to
3.1 to
3.11 to
NT (but not really because NT is a different code base) to
NT 3.5 (where did 1.1-3.0 go?) to
NT 3.51 to
NT 4 to
95 (wait, 95 is not from NT but from 3.11, right?) to
98 to
ME (except ME is a cross between 2000 and 98. 2000? Opps!) to
2000 (which is really NT 5) to
XP (which is really NT 5.5)
And, that is ignoring the the MS Server OSes!

My point? Each and every software product or project chooses and changes it's own version numbering scheme at will. Even proprietary ones.

Would it be good for all the project to follow the same numbering convention? You bet! But the confusion caused by the current situation is not limited to the FS/OSS realm. It is confusing or not based on how each software product does it.


Re:You mean like..

Posted by: Anonymous Coward on June 12, 2005 04:45 AM
Actually, MS identifies their products by thier build number. What you are showing is the "Market version"


Build number is not "public"

Posted by: alandd on June 12, 2005 05:58 AM
Normal users don't know what build number of Office they have. Normal users generally do know what build number of they have.

The "Market version" of FS/OSS projects is generally also the build version. Not so with MS products.

But that is neither here nor there. The main article has quotes like "...the FOSS world has gone mad and is hurling itself..." and "...that open projects are susceptible to these kind of non-technical pitfalls,..." throughout. The article fails to point out that closed source, proprietary software projects also use version numbers differently than the next. The article therefore implies that the problem is only present in FS/OSS projects.

My point was to show that the problem discussed is not unique to FS/OSS projects but is prevelant throughout the software industry no matter the development model.

Your point simply re-enforces mine. The "Market version" is not even the "Real version" so more confusion can result.

I actually find the article a bit silly. There is no way you will get every FS/OSS project, let alone all the closed source ones, to use version numbers the same way. It's like complaining that every retail store should use the same font, color, size and placement. Different version numbering schemes are part of the technical culture. Users have to learn it because it is not going to change.


If 10 people: a lesson in cooking.

Posted by: Anonymous Coward on June 14, 2005 03:52 PM
>> The "Market version" of FS/OSS projects is generally also the build version. Not so with MS products.

If 10 people comprise a company to shake and bake the consumers' wallets and purses, not all 10 will be developers. Some one (or more -- more likely) will surely be responsible for making sure the consumer knows just how much s/he wants, needs, and will find joy, peace, and happiness with the newest *version* of the product, whatever the version moniker.


Re:You mean like..

Posted by: Anonymous Coward on June 12, 2005 12:46 PM
I believe XP is actually NT 5.1, not 5.5. Your point is still valid, though.


Re:You mean like..

Posted by: Anonymous Coward on June 13, 2005 04:06 AM
WinME was not a cross between Win2000 and Win98 (despite what Microsoft marketting had told the world). It was Win98 -DOS Mode, +a few minor features, +a few more drivers. Also, the first version of NT was Windows NT 3.1 (and was that version to try and convince people that it was compatible with Windows 3.1).

There's also the Microsoft Word version number nonsense.
Word for Windows 1.x
Word for Windows 2.x
Word for Windows 6.0 (to synch with the DOS version number which had sequentially gone from 1.0 to 6.0 previously)
Word 95
Word 97
Word 2000
Word XP
Word 2003


Re:You mean like..

Posted by: Anonymous Coward on June 13, 2005 11:26 PM
I agree with you. One correction: Word for Windows 6.0 was actually numbered such to synch with the *Mac* version, because the Mac version has always been WYSIWYG. Your point is still valid, though.

Here's even more fuel for the fire. Sadly, Word for DOS 6.0 and Word for Windows 6.0, I found, used different file formats. I learned this when I gave my Dad Word for DOS 6.0 and he tried to read some WinWord 6.0 files. Didn't work. So MS wasn't even consistent, file-format-wise, within the same version number!

So, while version numbers can be somewhat confusing to the uninitiated, even in the Free Software world, Microsoft is much more egregious about confusion and switching up on folks than most Free Software projects are. Besides, I prefer anyway because, for what I do, it gets in my way less and preserves my freedom much more than MS Word.


Issue of minor importance

Posted by: Anonymous Coward on June 12, 2005 03:22 AM
I think that the iusse of the precise way of version numbering is not that important at least as different ways between the Linux kernel and gcc is concerned. I belong to the people who regularly compile both, Linux kernel and gcc from the source, in many different versions, also intermediate (-pre? and -rc? releases) and I have never been confused because of this (and I am not a specialized developper). Most users who do not compile themselves kernel or gcc don't need to care about the exact version because they use out of the box Linux distributions with precompiled binaries and preselected versions from the distributor.

Looking at the web-sites of or gcc the versioning schemes are pretty obvious and they have a quite well defined pratical sense. As far as gcc is concerned one should also mention that a branch like 4.0.0 is available for downloading and compiling for some time before it obtains the full status of a release, such that a certain number of bugs are already fixed for the first *.*.0 release. Afterwards, the bug-fixing continues and one should use the latest release in one branch. However, the proper choice of the branch (caracterized by the first two numbers) is a different, actually quite subtle, issue because there are several branches in parallel and one should be careful for the proper choice. In particular the latest branches 4.0.* and to some extend also 3.4.* are not very suitable if you want to compile existing open-source or free software, especially the Linux kernel. Due to new functionality a lot of existing quite old code may be broken. For this one should use the more conventional branches 3.3.* or even 3.2.*. However, when developping a new program/software from scratch, then the latest branches are presumably more useful. For this reason some Linux distributions are shipped with two (or more) versions of gcc. I honestly think that the strategy of functionality versus compatibility is very subtle and that there is no easy way. However, if there is a problem with confusion for normal user than it is here and not with the exact way how versions are numbered. Quite often normal users want to install free software from source and encounter problems because they use a branch which is not appropriate, for example 4.0 instead of 3.3 (simply because it is the default choice in their Linux distribution).
This issue would in my opinion have made a much more interesting and relevant article.


My response

Posted by: Anonymous Coward on June 12, 2005 05:06 AM
<a href="" title=""><nobr>u<wbr></nobr> mber-pains.html</a>

I figured it was easier to respond in blog format than to write something like my response in a comment.


There are several points in this article

Posted by: Anonymous Coward on June 12, 2005 06:40 AM
with which I take issue, based on almost 20 years of both commercial and open source experience.


Furthermore: if you use decimal points as your major/minor delimiter, your users are going to ask you why<nobr> <wbr></nobr>.10 comes after<nobr> <wbr></nobr>.8, every single time. And the misunderstanding is not their fault, it is yours; the decimal point has a very precise meaning and has had for 400 years. You've chosen to overload it by declaring that in this one special context, it means something different. John Napier invented it in 1619; lacking his permission, don't try to assign new definitions and behavior to it.

Well, except that it's already clear that it is not actually a decimal point, just as soon as you see two of them in the same number.

2.9 is followed by 2.10. Cope.


When you get right down to it, the only purpose a version number serves is to denote the relative supremacy of one of those versions compared to another.

Nope. Version numbers actually have two important, and distinct, purposes. First: they make sure that someone attempting to support something actually knows what it is, and second -- and more important in the context of your piece -- they allow the user to evaluate the programming team's perception of the stability of a release. Alpha, beta, gamma or Release Candidate, and that metal you allude to, Golden, or Production release -- those things are on the version number for a reason: they allow users to decide whether to try installing and working with them.

They don't always mean the same thing: some projects' betas are more stable than other projects production releases... but they're usually pretty predictable within a project.

And if they say it's production, and you find a showstopper bug still open in their Bugzilla, at least you can feel justified in screaming at them.<nobr> <wbr></nobr>:-)


increment from 2.8 to 3.0 as OpenBSD does so effortlessly

Here, you demonstrate your lack of understanding of precisely the semantics which you imply you understand earlier, when you said

Historically the point-oh release signified a finished product.

So, which is it?

2.9 is followed by 3.0 just because we want to avoid 2.10? Or do we acknowledge that 2->3 is a major change, and run with the 2.10? (Hint: the latter is much more sensible, regardless that you have to explain it to the great unwashed.)

Oh, and

Sun famously decided to leap forward from Solaris 2.6 to Solaris 7


No news. SCO did this with Unix (referring to System V release -- which followed -- as Unix 5.0), and Sun is currently doing it with the Java Runtime Environment, which moved from 1.4.2 to (1.)5.0.

All it does, really, is confuse users, beyond the ability of us geeks to explain it to them. We really wish they'd stop. There are <a href="" title="">Good Enough approaches</a> out there already.


Re:There are several points in this article

Posted by: Anonymous Coward on June 13, 2005 12:18 AM
Well, except that it's already clear that it
is not actually a decimal point, just as soon as
you see two of them in the same number.

Although I partially agree with the second idea
here, I disagree with the first...

Non-integer version numbers started off using
the very typical meaning of a decimal point...
Version 2 meant the second major complete
release, version 3 meant the third, and if the
author made a big but not full-version-worthy
improvement midway, they would use 2.5 to indicate
that... A version half-way between 2 and 3.

That extended to include more-or-less regular
updates, such as 2.1, 2.2, 2.3, and so on. Still
following decimal-point rules.

But then, somewhere along the way, an
author got to the version after 2.9, but didn't
have something he could call 3.0. So, we got
either "2.91", in keeping with decimal rules,
or "2.10", probably cute at first, but it opened
the floodgates for the mess we have now.

Next, we had the addition of bugfixes and
patch-levels, that added on another decimal
point... 2.4.1, the first patch to 2.4. Still,
though, it basically followed decimal rules,
and violating them only confuses people.

Personally, I prefer a scheme whereby it will
always monotonically increase, and has a well
defined number that takes no consideration of
progress to figure out - The compile date.
Now, that still leaves some ambiguity in the
open source world when you might have a dozen
project forkes, but I see no neat way to deal
with that other than to give the forks different
names, and let the user suffer figuring out which
fork they want. But once they know that,
they can instantly identify the most recent

And as for "beta" versions - A word of advice to
my fellow coders - STOP RELEASING THEM!!! Yes,
you can give a few freinds a copy to test, but
do NOT release known-unstable code to the general
public. If such a beta somehow slips out, just
refuse to acknowledge it - Answer any questions
about it with nothing more than a link to the
most recent "real" version.

And that, I think, explains most of the problems
with versioning - People need to stop releasing
versions that should never have seen the light
of day. If you know for certain that you'll
need to release an update in a month to fix all
the known bugs - Don't release anything
for another month!


Don't release betas?

Posted by: Anonymous Coward on June 13, 2005 03:08 AM
Well, there goes MythTV, then.

And *lots* of other code.

The short answer is that you can't *not* call it beta until you've had a wide enough audience test it, and if you're an OpenSource project, releasing is the only way to do that. You don't have to *call* it beta, but it's more intellectually honest to do so, IMHO.

I was the original author there; I see I didn't sign my message. Oops.

<a href="" title=""></a>


Re:Don't release betas?

Posted by: Anonymous Coward on June 13, 2005 09:53 PM
Or you could do it the Google way where nothing ever gets out of beta. How long can a project really be called a beta? Google's beta versions that last for a year or more are simply ridiculous.

Personally I think it's a cop-out for when people complain that a feature isn't working. Then Google can simply reply that it's a beta and it will get fixed in a future release. They're afraid of commitments.


Re:Don't release betas?

Posted by: Anonymous Coward on June 13, 2005 09:59 PM
Since when do you need a "wide enough audience" to test some code? For some "very large" projects, such as the Linux kernel, having a broad alpha/beta-test base is a good thing. But for small to medium sized projects you certainly don't need 3000 developers across the planet to give you the thumbs up before you mark your code as "working".

For a lot of projects (especially those using automated testing and unit-testing) it's very simple and suitable to do the testing yourself. Beta should mean that "it's suitable for someone without detailed knowledge of the code to run it and it does what it's supposed to do", i.e. no obvious showstopper bugs... sure there will be bugs in it but it will do something useful...

Also, since when does "releasing the code" == "you can call it beta"... again you don't have to have the planet review your code for you to know that it works and be fit for purpose...

I think the previous poster was indicating that there is little point in releasing unstable code since it costs everyone time and effort that could have been better spent getting it right!


Two sides to the coin: End User vs. Developer

Posted by: Anonymous Coward on June 14, 2005 04:11 PM
Don't give me anything but S-T-A-B-L-E, please.

Give me all of your alpha's, beta's, subversions, and gits, please.



Posted by: sakshale on June 16, 2005 04:13 AM
Sun is a classic example of versions being different, depending on who you are talking to... marketing, support or development. (or some such mishmash)

Is is Solaris 9 or SunOS 9.0 or SunOS 5.9?


Re:There are several points in this article

Posted by: tsg on June 14, 2005 04:04 AM
2.9 is followed by 2.10. Cope.

Whether or not it is a valid notation is not the point. It is confusing and that is the point. You're also ignoring that when the releases are sorted in an ftp directory they show up out of order. That is confusing and that is the point. It can be perfectly valid and still a bad notation.


Using a Version Non-Number

Posted by: Prototerm on June 12, 2005 07:07 AM
Of course people are going to look at a version number of<nobr> <wbr></nobr>.10 and assume it's a decimal. You just called it a number, didn't you? The most interesting version number I've come across, though, was at one shop that used a version number like "20050611". Didn't like it at first, until I realised how easily it sorted (you have to use two digits for 1 to 9, of course, to make it work) wherever it was used, and how it communicates to the user the only fact they really care about: what is the latest version of the software.

Still not sure if I'd like it for everything, but for internal corporate apps, it seems to do the job nicely.


Re:Using a Version Non-Number

Posted by: Anonymous Coward on June 13, 2005 05:19 AM
Datestamps like that are normally used to indicate a nightly build, though I've seen one or two projects that use them for stable releases too...


Re:Using a Version Non-Number

Posted by: Anonymous Coward on June 13, 2005 10:10 PM
And of course you have to have the same year/month/date ordering convention otherwise you can get yourself in a muddle...

Not everyone lives in the US you know<nobr> <wbr></nobr>:)


Re:Using a Version Non-Number

Posted by: Anonymous Coward on June 14, 2005 04:19 PM
>> Not everyone lives in the US you know<nobr> <wbr></nobr>:)

Running the numbers together (eg, 20050614) is just like the ISO standard. It is easy to recognize when you get used to expecting 20xxyyzz or 19xxyyzz. It should not confuse because it orders the time periods by their "size." [you can go further and attach hhmmss.... for hour, minute, second,....]


Re:Using a Version Non-Number

Posted by: Anonymous Coward on June 14, 2005 05:02 PM
As with any "convention" you have to know what it is for it to make sense... You are applying a "standard" to the number, but the standard applied is not apparent in the numeric encoding... even if you put ISO-20050614 you still have no idea what it means... as you say "when you get used to"...

In which case it is just as easy to use:


for the same reasons... Of course you then still have timezone issues, especially if you release builds on consecutive days... as I indicated, not everyone lives in the US... or the same timezone, or in the same "day"...

There is no such thing as an "intuitive" standard...


Re:Using a Version Non-Number

Posted by: Anonymous Coward on June 14, 2005 11:33 PM
"In which case it is just as easy to use:


for the same reasons"

Horsehockey. The date versioning number mentioned relates to something that more or less everyone is familiar with, the only explanation required is the order of the numbers. You can simply say, "It's a year, month, day version number," and everyone will be able to follow it immediately. I defy anyone to explain your example as simply.

"Of course you then still have timezone issues, especially if you release builds on consecutive days... as I indicated, not everyone lives in the US... or the same timezone, or in the same 'day'..."

More nonsense. It doesn't matter where "everyone" lives; it only matters where the developers release from, i.e., that the builds are all released from the same time zone. You have to be able to judge them in relation to each other, not compare them to your watch.

Of course, there are still problems with a completely date driven format in that it only conveys one piece of information, the date, and this is not really enough.

By the way, YYYYMMDD (with or without extra symbols as separators) is not a standard convention in the US any more than it is anywhere else. I don't know of a place where this has always been the norm for date notation. This is a relatively new standard, initiated specifically for computer storage purposes based on alphabetical sort routines, not based on a US date notation. The US standard notation is the nonsensical MM/DD/YYYY, which anyone would find confusing except by virtue of being used to it or being familiar with what it came from, the more fathomable format demonstrated like so: "June 14, 2005." Being from the US, this format is second nature to me, but it is clear to me that it doesn't really make sense when you are dealing purely with numbers.

"There is no such thing as an 'intuitive' standard..."

Perhas not, but that does not mean that an ordered system based on a previously established standard has no superiority over the nonsensical ravings of a lunatic mind.


commercial crapware

Posted by: Anonymous Coward on June 12, 2005 09:29 AM
IIRC, didn't all the versioning-as-marketing start with Sybase vs. Oracle, when Sybase took a hint from Spinal Tap (ours goes to 11!)?

And then there's Sun. Solaris 10 is actually Solaris 2.10, but if you do uname -a on a Sun box you'll see it's actually SunOS 5.10, to make it consistent with the original SunOS which went to version 4...


Not a bad article...

Posted by: Rob Park on June 12, 2005 10:19 AM
... but you forgot to mention gaim, which had a totally meaningless 1.0.0 release (eg, 0.82.1 -> 1.0.0 did not make any significant changes to the code, just the usual bugfix type release). Also, 0.59 to 0.60 made a huge change, namely gtk1 to gtk2 switchover.

Also, I'd like to make a case for date-based version numbers. I agree that ubuntu's "5.04" (year.month) versioning scheme is a bit confusing, but that's only because they dropped the century and are using the confusing decimal). If you use versions like YYYY-MM-DD, then you get a few advantages:

  • lexical sorting, newest versions always come first (or last, depending how they're sorted, but the important bit is that they're in order)
  • by using hyphens you avoid decimal point confusion, nobody will question why "-10" comes after "-08" because clearly the 10th day of the month is more recent than the 8th.
  • sure, the numbers in the date are fairly meaningless when it comes to figuring out if a release is stable or development, but then as you've shown, regular version numbers are fairly meaningless in that department, too.

Although I will concede that a version number like "2005-04-01" is kinda long and ugly for general use. I think what these software projects should do is just use the release date as the version number in technical situations (like in the names of source tarballs for example), but they should use named labels to indicate major versions (sort of like how Ubuntu went from Warty Warthog to Hoary Hedgehog to Breezy Badger, etc), just a name that nontechnical users can use, they are just as arbitrary as version numbers but make more sense (and are more memorable).


Think of Tex Version

Posted by: Anonymous Coward on June 12, 2005 12:13 PM
This is TeX, Version 3.14159 (Web2C 7.4.5)

<a href="" title=""><nobr>-<wbr></nobr> faq/FAQ18.html</a>

after TeX version 3.0 was released; at each bug-fix release the version number acquires one more digit, so that it tends to the limit pi (at the time of writing, Knuth's latest release is version 3.14159).


get a life, people

Posted by: Anonymous Coward on June 12, 2005 02:00 PM
What's wrong with you people? Look how much time and effort and typing that has gone into a discussion of version numbers....??

Who cares?


Re:get a life, people

Posted by: Anonymous Coward on June 12, 2005 08:12 PM
> Who cares?

The people writing the software you use everday care.

One of the fine distinctions between marketers and engineers is that marketers will assign a number based on "feel good" value, whereas engineers strive to find a number which communicates something specific to the user. As the article's author points out, this is a frustrating exercise, and no single, perfect solution has been found. It is only through discussions like these that we even have a chance of finding one.


Re:get a life, people

Posted by: Anonymous Coward on June 13, 2005 12:54 AM
I seriously doubt that you will ever get the sales and engeneering people to agree on a versioning system. They originated on different planets, and how they all got here is a mystery beyond comprehension. As you pointed out, the marketing types want something that feels good to the consumer, and the engeneer wants something that tells something about the status of his/her project. They might be able to come to terms except that there are the manager types who want the final result by 3 hours ago and don't care whether it works or not.

Then to complicate things, within the engeneers there isn't even agreement as to whether a software system is ever in a finnished state or not. Thus some pick a numbering system that indicates continuing work, while others pick a numbering scheme that identifies specific accomplishments.

To complicate matters, you have customers who want to know that the system they get has continuing development and support. You also have customers who don't want any changes to the software they use -- almost to the point where they would rather live with the bugs that plague them than to have them fixed and create any change whatsoever. Numbering systems mean different things to each of these two groups. What makes sense to one group makes confusion to the other.

By the way, how were we going to figure out a generic versioning system that was going to work for everyone? And you thought we were all just people.

I work with a sound system at the church I go to. I had a sound engeneer come in to go over things we can do to make the media systems more effective. Among other things, he pointed out to me that the best it is ever possible to do is to satisfy 85% of the people in the room at any time. With a group of 250 or so, that means that at best I will always have 35-40 unhappy people. The same ratios probably apply to most other areas of life. So, are you going to make the noisy 1% happy and risk creating another 1% that are noisy and unhappy, or are you going to try to reach the masses and let the 1% be noisy, or are you going to just do it your own way knowing that there will likely be a noisy 1% of discontents anyway?

Some things can not be perfected. This is, I believe one of the main reasons for having several compeeting systems or methods in each field. Now if we could just get the idea through people's heads that what works well for them isn't necessarily the perfect solution for everyone else we'd be all set. Oh wait. There will probably always be at least 15% of us humans that believe that their solution is absolutely the only one and everyone else is going to hell.


Re:get a life, people

Posted by: tsg on June 14, 2005 01:08 AM
What's wrong with you people? Look how much time and effort and typing that has gone into a discussion of version numbers....??

Who cares?

That you don't doesn't mean nobody should.

What's worse, that someone wrote the article or that you had to take the time to point out how little it matters to you? Nobody forced you to read it. Get a life yourself. Idiot.


What scheme *does* the Linux kernel use then?

Posted by: Anonymous Coward on June 13, 2005 02:02 AM
If Linux is no longer using the even/odd scheme then what is it using? I wrote some text at <a href="" title=""></a> explaining the even/odd scheme. Could anyone explain how it works now, or update the article?


Re:What scheme *does* the Linux kernel use then?

Posted by: Anonymous Coward on June 14, 2005 04:27 PM
OK, the reason why there has not been a odd numbered Kernel since the release of 2.6 is because the 2.7 branch has not been opened yet. Linus is going with the world in this, that the 2.6 series is up to par where it should be, and that if it is working fine, why open up the development branch.



Re:What scheme *does* the Linux kernel use then?

Posted by: Anonymous Coward on June 14, 2005 11:26 PM
So this article is wrong when it says the even/odd scheme is obsolete?


Re:What scheme *does* the Linux kernel use then?

Posted by: Anonymous Coward on June 14, 2005 11:48 PM
Sort of yes, sort of no. It is true that the even/odd version numbering is not in use right now even though there is kernel development going on. So in a way, no, the article is not incorrect, in that this versioning is not being used. However, Linus has indicated that when he feels that a change to the kernel is required that is major enough to warrant a separate development branch he will probably open up a 2.7 branch. At the very least the next stable minor version will not be 2.7, since odd number minor versions are reserved for unstable branches. It will either be 2.8 or 3.0. So in a way, yes, the article is incorrect that the even/odd versioning is obsolete.



Posted by: Anonymous Coward on June 13, 2005 04:43 AM
Point-oh releases used to be a significant milestone, implying a degree of completion.

Then came microsoft. By day I maintain MS boxes. Installing version ".0" would be regarded as very, very brave in a production environment. That has happened because of MS rush to market in the past (be fair: they are trying harder now; just not hard enough).

This is why the article that was being commented on referred to a 1.0.0 release as suspect.


Outlining as version release numbers

Posted by: Anonymous Coward on June 14, 2005 02:44 AM
Just for fun - here is an idea:

Use basic outline numbering to denote where in the "tree" your releases are. For example:

1. First release

  1.A First branch of 1

    1.A.1 First branch of 1.A

    1.A.2 Second branch of 1.A

      1.A.2.A First branch of 1.A.2

      1.A.2.B Second branch of 1.A.2

    1.A.3 Third branch of 1.A

  1.B Second branch of 1

    1.B.1 First branch of 1.B

  1.C Third branch of 1
2. A complete rewrite

  2.A First branch of 2


Yeah, right...

Posted by: Anonymous Coward on June 14, 2005 03:05 AM
If you're going to have to memorize that whole "Jth branch of Kth release of Nth branch of Mth release" chart, you're no better off than simply memorizing a "X.Y.Z" versioning scheme.

I can hear the user confusion with your scheme now, as they try desperately to remember if 1.B.1.A comes before 1.A.2.B or vice versa (completely ignoring the fact that they're different branches to begin with).


Just for FUN ??

Posted by: Anonymous Coward on June 14, 2005 05:14 PM
This reminds me<nobr> <wbr></nobr>...

[ <a href="" title=""><nobr>i<wbr></nobr> ?dbname=browse_usc&docid=Cite:+26USC1</a> ]

From the U.S. Code Online via GPO Access
[Laws in effect as of January 7, 2003]
[Document not affected by Public Laws enacted between

    January 7, 2003 and February 12, 2003]
[CITE: 26USC1]

Subtitle A--Income Taxes
Subchapter A--Determination of Tax Liability

Sec. 1. Tax imposed

(a) Married individuals filing joint returns and surviving spouses<nobr> <wbr></nobr>......

(h) Maximum capital gains rate

(1) In general

        If a taxpayer has a net capital gain for any taxable year, the
tax imposed by this section for such taxable year shall not exceed
the sum of--
(A) a tax computed at the rates and in the same manner as if
this subsection had not been enacted on the greater of--
(i) taxable income reduced by the net capital gain; or
(ii) the lesser of--
(I) the amount of taxable income taxed at a rate

  below 25 percent; or
(II) taxable income reduced by the adjusted net
capital gain;

(B) 10 percent of so much of the adj<nobr> <wbr></nobr>......
*****<nobr> <wbr></nobr>... I haven't figured out if my 26.A.1.A.I.1.h.1.A.ii.I is greater than my 26.A.1.A.I.1.h.A.ii.II or not?<nobr> <wbr></nobr>... is this how this is versioned?<nobr> <wbr></nobr>.. maybe I have to include -20030107?

Come to think of it, 26.A.1.A.I.1.h.1.A.ii.I-20030107 = 26.A.1.A.I.1.h.1.A.ii.II-20030107.


Of course it is fun

Posted by: Anonymous Coward on June 15, 2005 12:23 AM
I mean it really has got to be fun, otherwise we wouldn't have thousands of politicians mucking around with stuff like this.

It sorta goes this way:

1. Democrat move to suck up dollars and bloat the government.

  1.A Republican move to reallocate the bloat.

    1.A.1 Democrat move to reallocate the bloat.

      1.A.1.A Republican move to reallocate the bloat.

          1.A.1.A.1 Democrate move to reallocate the bloat.

  1.B Republican move to add a processing fee.

      1.B.1 Democrat move to reallocate the use of the fee.

        1.B.1 Republican move to reallocate the use of the fee.

            1.B.1.A Democrat move to reallocate the use of the fee.
2. Republican move to suck up dollars and bloat the government.

    2.A Democrate move to reallocate the bloat. etc. etc. etc.

<nobr> <wbr></nobr>....etc. and 256.A.1 Independent move to reduce the fee.

              256.A.1.A Bipartisan move to shut down the independent.

                    256.A.1.A.1 Media frenzy as politicians give speeches hailing the new era of party cooperation.


Other products

Posted by: siege_nf on June 15, 2005 03:07 AM
"Historically the point-oh release signified a finished product. Is it a point-oh release whether it's ready or not?"

The "point oh" issue isn't unique to software.

My father gave me a piece of advice about 15 or 20 years ago: Never buy a car the first year a new model comes out.


other anomalies

Posted by: Anonymous Coward on June 15, 2005 06:45 PM
IIRC Netscape jumped from 4.7 to 6.0 to match IE. 2.0 beta is called 1.9...


Re:other anomalies

Posted by: Anonymous Coward on June 16, 2005 04:32 PM
Alpha means working development snapshot
Beta works on testers platforms
Release all/most beta tester bugs are fixed

The fact the gcc developper aknowledge that only a full scale test by all users can show all the bugs make you wonder if they are professionalls ?

This is a troll<nobr> <wbr></nobr>:)

Nobody can release a program and believe in its own sake that no bugs or security issues are left<nobr> <wbr></nobr>...


Great article!

Posted by: Anonymous Coward on June 21, 2005 09:42 PM
I'm a developer (Java/J2EE , Perl), and really hate the version numbers of some Linux projects. It's just damn ugly!!

The Gnome example is the best. It's ridiculous to jump from 2.8 to 2.10, it absolutely makes no sense. The WINE example is another classic, using dates is just terrible, and I must confess, the impression I have from wine is that it's a beta software that doesn't even deserve a version number of its own, like the software we do on the boring Sundays afternoons, quick training stuff. It's a shame.

I think this version "confusion" leaves the system ugly.

As a Java developer, I must talk is javaesque, so a Design Pattern for naming and arranging software would be good in the Linux world.


too rapid is no good

Posted by: Anonymous Coward on June 22, 2005 07:31 PM
"Decelerating release numbers make outsiders think that development has slowed, and that misconception will hurt your user base. "

Rapid version number changes can also harm you seriously.
I personally won't touch a project that releases a new version every other day, it reeks or severe instability.
Many companies think the same way, and rightly so.

Indeed a numbering scheme should be transparent and consistent.
Make it well known which releases are for general use and keep those numbers consistent.
All minor releases below these are NOT for use outside the project (or else user beware), and no development should take place on anything that's not the latest public release (except bugfixes for paying customers and those should be retrofitted into all more recent releases).


This story has been archived. Comments can no longer be posted.

Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya