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

Linux.com

Feature: Free Software

Version labeling is out of control

By Bruce Byfield on June 07, 2008 (2:00:00 PM)

Share    Print    Comments   

Anybody who spends time trying new free software applications and distributions will soon notice that version numbering and labeling is next to meaningless. These days, versioning rarely gives an accurate idea of the state of development, except relative to other builds of the same project. It is simply a label that distinguishes one build from another. That's too bad, because a properly labeled release can give users a sense of how advanced the build actually is.

The problem is not that several different versioning systems exist. Once you realize there are variations, you should have no trouble picking up on the fact that the odd-numbered GNOME releases are development builds and even-numbered ones are official releases. Nor are you likely to mistake KOffice 1.9.95-4 for a late version of KOffice 1.0 for more than a moment before you realize that it is an early version 2.0 build. Anyone familiar enough with free software to be trying the latest builds knows that getting all of a large project's developers to agree on anything besides their mistrust of Microsoft is impossible. We learn to allow for idiosyncrasies.

Rather, the problem is that, no matter what the system, a version number often says nothing about how far along the software happens to be in the development process. Some projects, such as OpenOffice.org, have abandoned versioning except for the final release, and simply label each release as a build. But for every project like Firefox that forthrightly uses names such as "firefox3.0-rc1," dozens are using both the traditional three-digit version number and terms like "beta," "alpha," and "release candidate" so loosely that they no longer carry any meaning.

The way it should be -- and isn't

Version numbering, of course, is partly a matter of judgment -- a reality that Linus Torvalds frequently emphasizes when he announces a new kernel. For instance, five years ago, he announced the long-awaited 2.6.0 with, "This should not be a big surprise to anybody on the list any more, since we've been building up to it for a long time now.... Anyway, 2.6.0 is out there now." The implication that version numbering is arbitrary, and perhaps more a marketer's concern than a developer's one, could hardly be clearer.

Still, over the years, a broad consensus about what to expect in a release cycle has emerged. First come the development releases or nightly builds. Then, at some point around version 0.2 or 0.3, one release is declared -- somewhat arbitrarily -- the alpha release, which, in free software, designates a release in which major functionality is more or less enabled. Somewhere between versions 0.6 and 0.8, a beta is declared, meaning a version in which all the features of the major release are present, and the interface is almost finalized, but in which bugs are still being worked out. When all the showstoppers are fixed, one or more release candidates are released, and finally, a few minor fixes later, the major 1.0 release. The major release may not be bug-free, largely because of the problems of testing on enough different combinations of hardware, but it is supposed to be functional for most users.

That's what users have come to expect. The modern reality is somewhat different. Increasingly, I've seen releases with versions edging towards a whole number in which major functionality was still being implemented. When I reviewed BashStyle-NG, a desktop utility for customizing the shell, much of the interface was still in flux, even though I was using the third release candidate. In a more extreme case, KDE announced 4.0, and its development team then expressed surprise when people tried to use it in their daily work. Version 4.1 was what users wanted, they hurried to explain as the complaints rolled in.

Similarly, when the Foresight distribution has an alpha four release, then obviously the term "alpha" no longer carries meaning, even when you make allowances for the problems of a large project that consists of largely distinct modules. If a fourth alpha exists, then surely the first one was misnamed.

In a similar situation, Cyrille Berger, a KOffice developer, explains the fact that version 2.0 is now in its eighth alpha as due the size and complexity of the project. Designating so many releases as "alpha," he says, "is the only way to show that the project is still alive and is making progress." Berger acknowledges that "after the 2.0 release, we will follow a much shorter release cycle, with much fewer alphas," but meanwhile, the price is user confusion.

Consequences and solutions

When this out-of-control versioning errs in the opposite direction, it causes few problems. When FontMatrix's 0.1 release proved a fully functional font manager, I was pleasantly surprised. Not only was it software still in development that I could use without enduring any crashes or workarounds, but I couldn't help thinking that, if an early release was so polished, what heights would the official release reach?

But users who download and compile a release whose number or status is inflated are only going to have their expectations deflated. Instead of getting involved in the project and filing bug reports to help nurse development along, they are more apt to turn away in disgust, and it may be years before they return. And each time that happens, the project with inflated versions loses a chance to build its community.

<pLabeling a version accurately may be a management or marketing decision, but in the case of a free software project, participants are marketing themselves, and that should make them less reluctant to spend some time on the task. After all, if a project misrepresents itself, how can it expect others to regard it accurately? For public consumption, development teams are hardly bound by what their revision control software might assign.

Part of the problem, perhaps, is that version numbers are a legacy or an imposition from commercial development. Some might say they make no sense in free software, with its philosophy of "release early, release often." However, free software is increasingly commercial these days. If projects can compromise enough with business to have regular release schedules, then accurate versioning hardly seems too much to ask.

Or, if accurate versioning is impractical, one answer might be to adopt the loose categories suggested by Debian's cascading repositories: unstable, testing, and stable. That would be enough to tell users what to expect. Then official releases could be named more or less by fiat, the way that Debian has all along.

Whatever solution they choose, free software projects need to be more careful about versioning. Doing so would be doing everyone a favor.

Bruce Byfield is a computer journalist who writes regularly for Linux.com.

Share    Print    Comments   

Comments

on Version labeling is out of control

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

Version labeling is out of control

Posted by: Anonymous [ip: 84.69.189.20] on June 07, 2008 05:37 PM
Are you an idiot?
Confusion over an alpha release?

... So what if there are 8 alpha's? You expect it to go straight from alpha to beta? What about the number of bugs you miss in correcting that simple error - or the regressions?
There can be 200 'alpha' releases - and the terms of 'how close they are to release' depends on the feature set they're trying to achieve for the official Major/minor release.

Most people know that major's are for huge structural changes, minor numbers relate to big fixes to the code where people can experience 'bad things'(tm) and then anything after (alpha, beta, numbers) are reletively minor fixes and nightly builds..

--
Paul_one

#

Version labeling is out of control

Posted by: Anonymous [ip: 84.69.189.20] on June 07, 2008 05:52 PM
Oops - meant to say:

alpha/beta are SEPARATE from the release version.
alpha/beta ARE the two stages of the 'testing' arena - "bad unstable testing" and "should be stable for everyday use testing".. But still, at both stages the features can be added/removed.. Feature-locking doesn't occur until the RC's.

You seem to be combining both version numbering and release cycles - which are not exactly the same thing.

Also, the 'are you an idiot' question was not meant to offend, but simply an over emphasis.

--
Paul_one

#

Re: Version labeling is out of control

Posted by: Anonymous [ip: 206.222.198.12] on June 07, 2008 06:39 PM
I don't know, version numbers seem to be pretty easy to understand. I even got them when I was a beginner to linux. I think it's just one of those things you get used to.

#

Version labeling is out of control

Posted by: Anonymous [ip: 70.77.17.189] on June 07, 2008 07:14 PM
I sometimes see the opposite problem, namely mature projects with version numbers like 0.3. Some people are awfully conservative in their numbering.

#

Re: Version labeling is out of control

Posted by: Anonymous [ip: 122.17.153.133] on June 10, 2008 05:12 AM
Wireshark to name one

#

Version labeling: Know the Target Audience

Posted by: Anonymous [ip: 71.35.129.95] on June 07, 2008 08:35 PM

Arrrrrgh.



Release quality bars, feature implementation order, and which versions are deemed "feature complete" enough to warrant ongoing support, are all part of release planning. This has nothing to do with version numbers, and everything to do with project management (which most FLOSS projects don't have solid, dedicated resources for).



Communicating with potential users to indicate the project's maturity and feature-completeness; which versions are more stable vs. more featureful; the level of support that the project offers, and for which versions; and so forth, are all part of public relations. Again, this has nothing to do with (useful, development-driven) version numbers, and everything to do with marketing (which most FLOSS projects again don't have solid, dedicated resources for). Real Developers despise the ever-present "marketing" version number, because it defiles all the meaning carefully wrapped into a real version number to instead create a number that's easier to sell.



In FLOSS, there is a generally accepted (and practiced) numbering convention for the meaning of that major.minor.micro triple. Major bumps happen only when backwards-compatibility is broken (or made non-native, deprecated, or otherwise inconvenienced or jeapordized by future development). Projects with large major numbers are either a Bad Thing (they can't design and keep breaking their APIs to fix problems; the project keeps changing hands and being rewritten; they just don't care about backwards compatibility...), or are using a "marketing" version number. Minor version numbers indicate backwards-compatible changes -- almost always new features. Large minor versions tend to be a good sign -- the dev team is active, they release often, they're good about adding features, and they aren't breaking compatibility. Micro version numbers indicate bugfix level; large values here indicate that the team either focuses bug-fixing on designated releases (a good thing), or makes releases with lots of bugs (not so good).



People not following the above are out of line with the majority of the FLOSS world. But that's exactly why distros add an extra layer of translation, providing "stable" and "unstable" tags (not that they always get it right). It's a nice, pretty, marketing front-end -- which is far easier to digest than the life's story of every project out there. However, that's a completely different target audience than dev-to-dev, which is what the version number is intended for. Version numbers aren't out of control, so much as you're trying to use them for something they're really, really not meant to do: market.

#

Version labeling is out of control

Posted by: Anonymous [ip: 67.150.125.226] on June 07, 2008 08:36 PM
The real versioning problem is with distros that have decided to use meaningless designations such as Ubuntu's brain-dead month-year labeling. How am I to know how technically mature the distribution is if the last release is labeled April 2008 in numbers? Or, if you don't like that example, why did PCLinuxOS change from using a version number to using a year?

What I wonder is, what are these distributions trying to hide? Is it that they are actually technically immature, but they are merely interested in collecting users; so they provide a false sense of security through vague version labels?

That may be cynical, but I seriously wonder why some distributions have stopped using actual version numbers.

#

Re: Version labeling is out of control

Posted by: Anonymous [ip: 74.180.102.137] on June 08, 2008 06:22 AM
> How am I to know how technically mature the distribution is if the last release is labeled April 2008 in numbers?

Ubuntu contains thousands of software packages. What single version string can convey all the details of their maturity or immaturity? Everything is going to have greater or lesser degrees of polish and maturity, and it's not going to be evenly increasing across the distribution, or even at the same rate.

#

Re: Version labeling is out of control

Posted by: Anonymous [ip: 72.23.19.139] on June 08, 2008 05:23 PM
The project I run has been doing "timed releases" every 2 months.
Thus we use the month-year designation.
There is no more information in 8.2.0 than in February 2008.

If the user wants exact information about what code they are
running it is possible to ask git for the hashcode which identifies
the exact source tree. This has never been necessary.

We have a continuously growing set of features. Only those features
that are mature enough go into the time release, everything else waits.

Since the software is planned to be available and changing for the
next 30 years there is no need to "do marketing releases", aka
1.0, 2.0, etc.

#

Version labeling is out of control

Posted by: Anonymous [ip: 84.50.125.16] on June 07, 2008 09:44 PM
One funny versioning example that has bothered me for a while are Mozilla Firefox & Thunderbird - why the heck do they name their bugfixes as the 4th digit, a'la 2.0.0.14, even when some of the bugfixes are quite major, as they express it. Until 1.0 versioning was quite OK, but after that it got messed up - 1.0, 1.5, 2.0, 2.0.0.1, 3.0..

#

Version labeling is out of control

Posted by: Anonymous [ip: 67.68.125.76] on June 08, 2008 01:23 AM
I personally use the following scheme:

Years_project_started.actual_year.month-day
So for a project started this year (0) and we are june 14:

0.8.6.16

The same project next year i july:
1.9.7.13
A suffix like -alpha or - stable may be appended.

Only a simple and balanced proposition.

IMO

#

Re: Version labeling is out of control

Posted by: Anonymous [ip: 67.68.125.76] on June 08, 2008 01:26 AM
i meant: and we are june 16:

sorry

#

Version labeling is out of control

Posted by: Anonymous [ip: 85.179.219.121] on June 08, 2008 09:32 AM
About BashStyle-NG 5.0 and KDE 4.0: Both have been rewrites from scratch. Users of both knew that, or it was at least easy to find out, while reading all the development release anouncements. KDE 4.1 is on the way, BS-NG 6 has killed off every issue known as of now.

Furthermore I don't find the different ways of versioning confusing. I'm doing it that way:

beginning with 1.0 [.0 releases are known to be buggy]
continuing with major.minor+1 [ 1.1, 1.2 et cetera]
if there are big changes [UI/Code rewritten from scratch or so] major+1.0 [2.0, 3.0 et cetera]

I guess that's very easy to understand.

#

Version labeling is out of control

Posted by: Anonymous [ip: 81.241.250.213] on June 08, 2008 10:18 AM
I agree with Bruce: If you don't follow the projects closely, it is impossible to know what is a stable or unstable version, how big a change was implemented compared to the previous version, how far away a new major release is.

Examples:
The switch from linux 2.4 to 2.6 was a major change in the kernel but a rather small change in the version number.
From Debian Woody (3.0) to Sarge (3.1) it took 5(?) years, and the new release whas much different from the previous one (if I remember correctly Gnome was updated from 1.4 in Debian 3.0 to 2.20 in Debian 3.1). Nevertheless, the number suggests it was only a minor upgrade.
Then there are the funny questions like: What comes after a version 1.9? In some project the number is seen as decimal so 2.0 would be next. Others interpret the digits completely separately, so 1.10 would be next.

There are many more examples, where the numbering schemes between different projects are absolutely not comparable.
This is o.k.: Every project must decide by itself, how they want ot number - but for people not following the indiviudal schemes closely, the numbering then is quite irrelevant. And this is what the original poster wanted to point out.

#

blame the maintainer

Posted by: Anonymous [ip: 134.92.10.229] on June 08, 2008 11:51 AM
Bad versioning is happening for years and was introduced by marketing people that wanted to avoid the 1.0 (or so). It is bad that OSS maintainer follow that trend without need; bad habits a easy learned and hard to fight. People that release a 4.0 instead of a 4.0-preXXX either have no clue how to handle numbering in there versioning system or are to lazy to make it propperly. It is ok for the user to complain to this people for releasing a crappy software. I am maintainer myself an i know that they are thing: 4.0 means for them Version 4 (user and developer understand this) .0 (User: the first release of 4; developer: the experimental version of 4). Since the maintainer has the duty to represent the user inside the developing cycle -- his fault.

#

Version labeling is out of control

Posted by: big bear on June 08, 2008 03:29 PM
Could there be an opportunity for people to realize there are two sets of versioning numbers. One that devs, techs and admins understand and one that that end users are looking for.

The ewo groups have different expectations. The first group, for purpose of development tracking and keeping testing and progress straight, will use a much more convoluted yet ,to them, incredibly more descriptive, versioning system.

Users only want end results. They want to see "Final" at the end and a synopsis of what has been fix added or upgraded. They couldn't care less that it took the devs 12 attempts to get a certain aspect fixed. All they want is the end with it fixed.

For example, Inhouse, I might use a "test-t" version system, as opposed to the overused alpha-beta system.
If I am working on "Serverjoe" for release. we will maybe use "serverjoe-1-t1-bb" meaning this is serverjoe, destined for release 1,test , done by bb (me). Again, this is all inhouse and only relevant to inhouse deeveleopment team, be they other devs, people who are "testing" for bugs, etc, they are all on the same page and when making notes, we can pick out a specific test to return to or identify.

For the public, all they will see is "ServerJoe 1-Final" and a synopsis of all the goodies contained therein.

Perhaps one part of the problem with releasing public tests is that the end users aren't always the same people you expect to recognize a test from a final product, and are thus easy to confuse. The devs are most responsible for not communicating more clearly that what they have released is only a test and not intended for mass rollout..

Possible.

#

Version labeling is out of control

Posted by: Anonymous [ip: 24.68.206.237] on June 09, 2008 12:29 AM
Java release numbers are out of control. Is it version 1.5 or version 5.0. Is it 1.6 or 6.0?

#

Version labeling is out of control

Posted by: Anonymous [ip: 72.144.240.250] on June 09, 2008 02:53 AM
i posted that linux version numbers are joke on linuxquestions.org and i was bombarded with negative comments from linux community
it is big joke - so called programmer writes 2 line code which does not work at all and calls it version 1.0
one of the reasons why linux can not get much acceptance with general computer users is that linux has no control over developers - in contrast with apple and microsoft averyone can call himself programmer and get anything to pass as linux program - that includes both content and version number
unless linus gets a stick same like apple and microsoft have over their software developers i do not see any way for linux to get general desktop acceptance

#

Re: Version labeling is out of control

Posted by: Anonymous [ip: 24.217.97.32] on June 09, 2008 03:41 AM
wow...

just wow... dude..you're missing the entire idea of open source...

#

Version labeling is out of control

Posted by: Anonymous [ip: 76.231.46.155] on June 09, 2008 06:32 AM
There is a simple solution to this problem: the RubyGems rational version numbering system [1], which clearly and loudly indicates to the user whether any incompatible changes are included in a release. This "major.minor.patch" numbering policy is summarized as follows:


┌──────────────────────────┬─────┬─────┬─────┐
│Version number components:│Major│Minor│Patch│
├──────────────────────────┼─────┼─────┼─────┤
│ Backwards compatible? │no │yes │yes │
├──────────────────────────┼─────┼─────┼─────┤
│ New features? │yes │yes │no │
├──────────────────────────┼─────┼─────┼─────┤
│ Bug fixes? │yes │yes │yes │
└──────────────────────────┴─────┴─────┴─────┘


This numbering system is widely (and successfully, IMHO) used in the user community of the Ruby language[2].

[1] http://www.rubygems.org/read/chapter/7
[2] http://ruby-lang.org

#

Version labeling is out of control

Posted by: Anonymous [ip: 194.6.109.210] on June 09, 2008 09:18 AM
For distro's i like the version numbering of the month and year as i can tell at a glance a human readable version.

#

Version labeling is out of control

Posted by: Anonymous [ip: 195.50.35.4] on June 09, 2008 12:02 PM
I agree with Firefox being confusing (or confused, perhaps?). Having 2.0.0.14 and waiting for 3.0 is silly. I suppose we are unlikely to ever see FF 3.1?
Not to mention discussion why 3.0 is 3.0 - I am not sure it deserves such a number, at least feature-wise. Perhaps tech-wise - feature-wise it seems like... oh, dear... 2.0.0.14.1.

#

Version labeling is out of control

Posted by: Anonymous [ip: 70.173.62.25] on June 10, 2008 04:14 PM
I absolutely agree with this article. I'm not trying to promote OpenBSD by saying this, but one important thing that drew me to OpenBSD was the simplicity and consistency of it's versioning. A new version comes out every 6 months consistenly. No more two year waits for me. The version number releases increment like so 1.1, 1.2,...1.8, 1.9, 2.0, 2.1, 2.2, etc. consistently. None of this 1.1, 1.2, 1.3, then 2.0 crap. When I started out as a new user to Unix, this OpenBSD way was a no-brainer. I could stop using OpenBSD for 5 years and come back and just get it. With Linux, if I came back after five years, I'd have to remember, "was it the even numbers that are development releases or the odd ones? I better look it up. And what does 2.6.50-blah blah mean? Is that an alpha, beta, or rc or release? I better look it up."

#

Version labeling is out of control

Posted by: Anonymous [ip: 70.17.75.218] on June 10, 2008 05:47 PM
I've always thought that having releases designated by "point" was flat out stupid in the free software world. Why? Because free software lets a user take control and run whatever they want. A user who wants a stable server will be running something like Debian which prides itself over stability, but that same user on a desktop system may be running Sid. It is the user, and NOT the software developer who determines "if it's stable".

Also, since free software gives access to source code at almost every stage in development the differences between a point in time could be more signifigant than the version number.

Some projects have gone to using the svn or git revision date as the version. It doesn't imply that the software is more stable, more mature or better suited for any specific purpose, it simply means it's recieved some form of change.

#

Version labeling is out of control

Posted by: Anonymous [ip: 74.205.192.45] on June 11, 2008 07:58 PM
I agree with Bruce completely, other than being bothered by some projects having too many alphas -- if it takes 6 months to work out the bugs, and the projects feels like having like bi-weekly alphas, they'll just have a lot of alphas.. it's not a real problem. Otherwise, he's right -- open source projects can do what they want, but it really is confusing to have some projects just expect you to know if a release is stable or not; KDE 4.0 exemplifies this. They had all these 3.99 releases, based on that logic 4.0 SHOULD have been in a reasonably usable state, but wasn't so much. The other prime example for me is the Linux kernel; Linus' new attitude of "let's just put new stuff in the 2.6 series and see what happens, distro makers can sort it out." It's working OK due to git trees doing the heavy testing, but it's still a far cry from previously where, for instance, you could know 2.3.x and later 2.5.x series were possibly buggy, but 2.4.x would get more bugs fixed with each release rather than 2.6.x where some bugs fixed and others introduced by having new code tossed in.


#

Version labeling is out of control

Posted by: Anonymous [ip: 72.93.168.178] on July 04, 2008 02:58 AM
With regards to KDE4 perhaps because I was following it I was fully aware of how buggy and incomplete it would be. I saw ample evidence of their attempt to warn people off. The version number was tricky but if you think about it they didn't have a lot of options. People needed to know what the most recent version of 3 was for the reasons you mentioned. It is still KDE but is very different software. When I was trying out Firefox 3 I was well aware that it would be buggier than the latest version of 2. If KDE marketed a different way it would have been even more confusing and misleading. Releases like Firefox 3 and KDE4 can't simply subtract .05 from their whole version number when they change the software and features drastically. We would probably need everyone to start doing it their (KDE's) way and that probably won't happen either. I think you as much as made the point already.

#

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



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya