Version Numbers and You

July 28, 2003 7:17 PM

Seen in the Ruby Application Archive:

FooApp v0.34 FooApp for Ruby with a user friendly API, akin to BarApp, but feature complete and significantly faster.

Dude... if it's feature complete, why is it only version 0.34? (To confuse matters a little more, the long description page lists it as being “Production Quality”)

Too many Open Source projects treat Version 1.0 as some kind of Holy Grail that can only be reached when the project is perfect. I find that highly annoying, because it makes it really, really difficult to tell a sketchy alpha from production code that is just still in pre-1.0 because the author wants it to do everything.

My best advice to anyone thinking of starting such a project: put together a road-map now. List the features you want to see in your program, and then cull it down to three milestones:

  1. The bare minimum you would need to implement before you let anyone see your code.
  2. The bare minimum functionality you would need to implement before people could legitimately make use of your code
  3. As above, but stable and well-documented enough to be used in a production system (for libraries), or by non-programmer end-users (for applications)

Milestone 1 is your v0.5. Milestone 2 is v0.9. Milestone 3 is v1.0.

Note the “Minimum”. If you are over-eager, you will fall into the same trap as the programmer who developed FooApp: a version number that contradicts the documentation in terms of how useful the application may in fact be. Don't cull so far that you're releasing something you wouldn't use yourself, but don't fall into the trap of thinking that 1.0 is some magic number you will achieve when you've implemented everything.

The plan may be subject to change, too, especially if you find features being contributed by interested developers. However, if you start with a plan, you'll find it (and more importantly your users will find it) easier to plot how far you are from the magical stable release.

The idea is to get something by 1.0 that is useful, useable and stable. After you have accomplished 1.0, you can sit down and come up with a similar road-map for 2.0.

2 TrackBacks

Listed below are links to blogs that reference this entry: Version Numbers and You.

TrackBack URL for this entry: http://fishbowl.pastiche.org/mt-tb.cgi/314

0.0.3.4a useless from Pensieri di un lunatico minore on February 8, 2005 1:04 PM

Please, if you release software to the public and consider it usable and reasonably stable, do not number it some... Read More

I try not to just regurgitate content from other blogs, but "this post":http://fishbowl.pastiche.org/mt-tb.cgi/315 by Charles Miller over on "The Fishbowl":http://fishbowl.pastiche.org/ is

Read More

4 Comments

I like the disassociation between version numbers and "good" releases myself.

I like the version number just be a number. It lets me know when something has changed and most of the time that's all I care about (as long as there is a change log to let me know what changed). I look to other documentation to let me know the code quality and readiness of the application for prime time.

The developers idea of what is finished often differs from mine (in both directions) - and the "just a number" approach of open source projects is a refreshing change from proprietary software's version number inflation.

I like the disassociation between version numbers and "good" releases myself.

I like the version number just be a number. It lets me know when something has changed and most of the time that's all I care about (as long as there is a change log to let me know what changed). I look to other documentation to let me know the code quality and readiness of the application for prime time.

The developers idea of what is finished often differs from mine (in both directions) - and the "just a number" approach of open source projects is a refreshing change from proprietary software's version number inflation.

Have to agree with Charles, how are you ever supposed to convince management or other stakeholders that an open source library is worth using if the developers haven't got the guts to put a real number on it? If it says ZERO point, its zero, nuthin', nada etc.

If its just a number, why have the zero at all? Its use is redundant if it is never going to be updated.

I agree that inflated version numbers given artificial meaning is a worse sin than unaesthetic numbers. Major version number (everything before the period) changes should represent ideological shifts and non-backwards compatible changes.

If FooBar 0.34 sounds bad to you, just call it FooBar in front of the PHBs. If you're in charge of the project, start with 1.0 (or 1.1 if you think ones should be beginnings) instead of 0.0 or 0.1.

Comments are no longer being accepted for this blog entry. If you really want to make your voice heard, you can always email me.

Previously: Crimes Against Humanity Currently Committed By This Weblog

Next: The (d)Evolution of Online Communities: A Case Study