The Installer

The first screen of the Windows installer for OpenOffice.org asks a question which most users won't know how to answer, and gives them the wrong default.

It asks the user where to unpack the temporary files needed by the installer - files which the user should never need to see - and defaults to unpacking them on the user's desktop.

There are several things wrong with this dialog:

1. It doesn't tell you why you'd ever change it. The way the dialog is worded, it sounds like the product itself will live in the selected location. But in actual fact, the only situations I can think of where you would need to change it are if you have limitted space on a particular disk partition, or an unusual permission setup. The default wording should reflect this:

   "The LibreOffice installer needs to unpack some temporary files to proceed. This will require roughly XMB of space. If the location shown below is not appropriate, please specify an alternative location."

2. The desktop is not a temp folder. The "desktop cleanup wizard" is one of those bits of Windows that should never have been necessary, and it is abuses like this that mean it is. Quite simply, the default location for temporary installation files should be the temp directory provided by Windows.
3. More subtly, these files aren't actually cleaned up. This is possibly the reason (or, excuse) for unpacking to the desktop rather than a temp folder: a successful installation of OpenOffice.org currently leaves a folder of unpacked installation files lying around, and it's up to the user to notice and delete these. I can only imagine that there are some problems with the installation executable deleting itself, but surely a stub could be placed in the permanent install directory to clean up the files once everything else has finished?

The Help Assistant

The OpenOffice.org Help Assistant cunningly implements the least popular part of Microsoft's infamous "Office Assistant" feature - the cutesy cartoon graphic that pops up while you're working - without implementing its actual purpose - showing context-sensitive tips with a minimum of user interaction, and without using up too much screen space.

If the light-bulb graphic pops up while you're typing in a Writer document, you know that the help system is trying to tell you something. But you know absolutely nothing else - there is no polite speech bubble, no hint if you mouse over the icon, nothing at all until you click the icon at which point a full-size help window appears (and, in my experience, appears slowly). This is, frankly, worse than useless.

The simplest solution to this, frankly, is just to remove the feature. But if they really want this feature, then there is a small change that would change it from completely pointless to actually quite helpful: show a one-line summary of what the tip is actually about, before you click the graphic!

Conditional Formatting in Spreadsheets

This one isn't such a big deal, really, but it's one of those little details that puts people off switching from, ahem, rival applications. It's also one of those cases where a bit of pragmatism is required.

Basically, if you want to have the formatting of cells in a spreadsheet in OpenOffice.org, you have to specify a named style for each rule.

Now, don't get me wrong, the style manager is one of the things I really like about OpenOffice.org when I'm working in Writer - to me, it makes all the difference between a "rich text editor" and a "word processor", and is much better than the versions of MS Word I've used. I can also see the reasoning behind allowing any styling to be applied by the conditional formatting, and the interface makes it easy to add a new style if you need to.

But 99% of the time, people will want to change two aspects of the matched cells: the text colour and the background colour. This is all most spreadsheet applications allow you to change, but they allow you to change them really easily. So, I'm happy for a new style to be created behind the scenes, but can I please have two little boxes labelled "Text colour" and "Background colour"?

Yeah, I know...

It's open source, I should

1. Check the issue tracker for previous discussion of these issues.
2. Download the source code and fix them myself.

But, y'know, I have to go and make some dinner now. Nobody's perfect, eh?

By an interesting coincidence, just as I was thinking about this post, I came upon Tom Preston-Warner's "Semantic Versioning Specification", which covers some of the issues nicely. But while he is mainly considering the problems of "dependency hell" - very important to consider when writing a library or tool which is likely to become a dependency for some other project downstream - there are wider issues with what a version number means to people, even if you are making a desktop application for use by "ordinary folks".

So, here are my "Golden Rules of Version Naming" - as with everything in life, they are often mutually contradictory, and full of exceptions; life is all about compromise, but that doesn't mean you have to compromise everything.

Be Consistent

Be Consistent About Progression

The most obvious thing that a version number should show is an obvious and consistent progression - the numbers should be getting higher, in some meaningful way. This may sound so obvious as not to mention, but it's possible to get it wrong - consider:

• The current version of pgAdmin - the popular open source desktop admin tool for PostgreSQL databases - is pgAdmin III 1.10.1. Now, I don't know the history of the project, but presumably at some point "pgAdmin 3" was started as a major rewrite of "pgAdmin 2"; but why not simply start it at version 3.0? The only reason I can think of is that they wanted to have "0.x" releases of the new codebase; but this is hardly an unsolved problem - Firefox 3.0 had 8 Alpha and 5 Beta releases without needing to reset to 1.0 afterwards...
• The incredibly popular Street Fighter 2 was infamous throughout the '90s for increasingly hyperbolic "edition" names, such as "Super Street Fighter II Turbo". To be fair, it seems a Street Fighter 3 was finally released in 1997, although that too received 3 "editions".
• An interesting problem comes up if your versions aren't just numbers. Ubuntu releases have both a version "number" which is actually an abbreviated year and month, and an alliterative animal code-name (such as "Dapper Drake" for version 6.06). Cunningly, these code-names are now being assigned in alphabetical order, so you can tell at a glance that an "Intrepid Ibex" is more out of date than a "Karmic Koala".

Be Consistent in Your Logic

It's also important to be consistent with your own versioning scheme - you could adopt "Semantic Versioning", or something like it; or perhaps you could adopt the convention used by Linux, GNOME, and others that "every odd minor release is unstable" (so Linux 2.4.x was stable, and once 2.5.x became stable, it was renamed 2.6.x), but either way, you need to decide early on, and stick to it.

• A recent failure of this is Lightning, the popular calendar plugin for Thunderbird. Having released versions numbered from 0.1 to 0.9, they released something called "1.0 beta 1", the first release compatible with Thunderbird 3. This led to plenty of users - myself included - waiting patiently for version 1.0, which was presumably just around the corner. Wrong - the developers clarified the situation with a blog post proclaiming this "the best Lightning release ... released to the public". Evidently, they considered 0.9 to also be a "beta" release, but in that case surely this is not "beta 1" but "beta 10"?
• Sometimes, of course, you define your convention wrong, and have to change it; Firefox 2.0.x.x had a very strict four-part versioning scheme. However, in practice, the highest release in that series was 2.0.0.20; so they waited until version 3, and revised it to have just three parts, as in version 3.5.8.

Be Consistent Across Related Products

If you have a series of closely related products, or products which you sell as a bundle, it's a good idea to give them consistent version names.

• The prime example of this is probably Microsoft Office, which originally bundled together separate versions of Word and Excel. As the suite began to gain more common functionality, branding, and additional tools, Microsoft decided to give every program in the suite the same version, starting with 7.0 for Office 95 - even though only Word had reached 6.0, itself skipping versions 3, 4, and 5 on Windows as they had been used for separate Mac releases.
• An interesting case it TortoiseSVN, which is built against the strictly-versioned Subversion libraries. Most (but not all) fixes to underlying Subversion code require a new version or Tortoise, but there are also bug and even functionality improvements to the interface itself. The solution they've chosen is to track the first two parts of the Subversion version, but track there own releases with the third part - so the latest version is 1.6.7, built against Subversion 1.6.9.
• The author of the Lightning Provider for Google Calendar extension fell foul of this consistency when updating to support the badly named "1.0 beta 1" release mentioned above - the extension had only reached version 0.6, but he duly added "beta 1" to the name, explaining thus:
  

  "Even though the version number suggests this is beta level software, it has been tested just as well as the previous releases. The naming is aligned to the Lightning version numbers."

• Although careful with their over-all logic, the Mozilla project has a rather odd inconsistency between the internal branch versions of the "Gecko" core and the applications built from it. Namely, Firefox 3.6 is Gecko 1.9.2, while Thunderbird 3.0 is Gecko 1.9.1 (as was Firefox 3.5); these apparently follow a very slow progression from the versions of the original Mozilla suite, which ceased at version 1.7.13 three years ago.

Be Consistent With Your Branding

The naming scheme that makes sense for programmers may not make for great branding, and vice versa; but that's no reason not to at least attempt to keep version-like branding consistent with your actual versioning.

• Probably the most famous failure of this recently has been Windows 7 - not only does no-one know why it got that name, but its internal (kernel) version number is actually 6.1 - if you want to concoct your own theory, you can consult my handy table of Windows versions. At some point, a version of Windows will presumably be released with an internal version number of 7.0, leading to the fun of distinguishing "Windows 7" from "Windows version 7.0". I guess if they have any sense, the developers can skip the internal version to 8.0...
• On the other hand, MacOS X, despite being an almost entirely different system from MacOS 9 and earlier, has had subsequent releases numbered as 10.1, 10.2, and so on, so that the "X for 10" branding is still valid.
• Sun's branding around Java is (or has been) a total minefield; my favourite example is a paragraph from Computer Weekly magazine, which I unfortunately no longer have, but went something along the lines of "at the upcoming JavaOne '03 conference, Sun will launch the Java2 J2SE JRE 1.4, along with Sun One Studio 5 and Sun One Application Server 7" (versions based on this article, which is almost as bad). If "Java 2" was so much better than "Java 1", why did none of the tools receive a major version increment!?

Be Bold

Be Bold With Numbers Above 9

A common problem with version numbers is that they look like decimal numbers - version 0.2 looks like something you can do maths with, and version 0.2.0 could just be "0.2 with a .0 stuck on". This leads programmers to the quite erroneous assumption that unless they started with 0.01, they will run out of digits at 0.9 - there is nothing wrong with version 0.10.

One way to look at this is that version strings are numbers, but not in base 10 but some arbitrarily high base; the dots aren't decimal points, they're to separate the "digits", each of which is written in base 10 to keep the alphabet small. Or just say "it's not a number" and get on with it.

The only problem comes when trying to sort lists, such as files in a directory, but that's because string sorting algorithms are generally pretty awful at sorting numbers anyway - this is not a bug in your naming convention, it's a bug in your file manager.

• This is probably what caused the mess with Lightning mentioned earlier - having reached version 0.9, but not ready for the big 1.0, the developers panicked, and picked a confusing fudge. If they'd stuck to 0.10, they could have carried on with 0.11 if necessary, and no-one would be in any doubt what they meant.
• Another great example is Flyspray, a bug tracking system which branched for 1.0, then seemed to approach it asymptotically with increasingly daft version numbers, including 0.9.9.5.1! Sadly, the project seems to have stalled, and I suspect it's unlikely 1.0 will ever be released.

Be Bold With Major Versions

The other thing developers are always reluctant to do is increase the "major" version number. Projects will continue for years on versions in a 1.x - or even 0.x - sequence, because the new version is somehow never "quite different enough". Indeed, given a three- or four-part versioning scheme, people will try to mark as little change as possible - version 1.1 happens far more often than version 2.0, but the actual change varies wildly.

This, in part, is what the "Semantic Versioning Specification" is trying to solve (he even covers the 1.0 problem in the FAQ). But in general don't be afraid of version 1.0, or 2.0; and every now and then, when planning the next release, ask yourself "why not bump the major version?"

• One of our main projects at work for a long time had 2 main branches, numbered 2.3.x and 2.5.x. Eventually, someone decided it was time to call it 2.6, but we continued to have releases like 2.6.2.5 until we could reset the scheme (like Firefox!) with version 3.0.
• This is, of course, what motivated both Lightning and Flyspray to odd release numbers - they didn't feel they'd "done enough" for version 1.0
• This is also part of the problem with pgAdmin - how many times can you release 1.0, and update to 1.x, before you have to admit you've reached 2.0?
• On the other hand, one project that has recently made a considered decision to bump a major rather than minor version number is PostgreSQL itself - the next release will be not 8.5 but 9.0