This rant started as a comment to Jeff 'Coding Horror' Atwood's recent posted entitled "What's In a Version Number, Anyway?" In his post Jeff take a look at some of the What, Why, and How software gets its version numbers and how those influence the product's name.
The topic is particularly interesting to me as not too long ago Phil and I were discussing a possible change in the naming scheme used for Subtext. Anyone who has been following Subtext development (and releases) lately has probably noticed the flurry of version numbers that are leaking into the product name.
Subtext releases to date:
Up to and including the 1.9 release I didn't mind having the version number included in the name because it was an easy way to distinguish between the various flavors available. However now that there are 4 different 1.9.x releases alone it is starting to get a bit ugly and possibly confusing for users.
Keep in mind that we (the Subtext Project) do have a pretty sweet CI setup that automagically versions each build in an incremental manner. So internally the product has version numbers that follow the MSDN Versioning Scheme and I realize the need to keep those version numbers around for tracking purposes. However, I'm more interested in how to name a product - using the versioning scheme as a basis.
What about cute names?
We do give each release a codename that is supposed to follow a nautical theme (though a couple of times we've strayed away from that), but even those "cute" names don't clearly distinguish the progress of the software. I have the same problem with how Apple names each release of OS X.
Don't get me wrong, the code names are nice as they give each release a little character and they help for tracking and discussing the product. I mean, it sure is easier to talk about the Windward code set or release than it is to have to say "Oh, you're still running on the version-one-dot-nine-dot-two code..." That is just a big mouthful and sounds way too much like geek-speak for the average user.
Why not take a cue from the big guys?
As Jeff mentions, Microsoft has (for the most part) moved away from using version numbers in the consumer-friendly names of their products. They tend to use either the yeah (as in Office 2003, Office 2007, etc...) or marketing speak in the case of Windows XP and Windows Vista.
Those naming conventions work fine for products that have release schedules that span a couple of years. But using the year as part of the product name/version quickly fails when we're talking about software that releases several times per year. A good example is Subtext.
Since or goal is to release early and often we will ideally be pushing out a new release every 3 to 4 months... or at least twice a year. So how would you fit a year into our naming convention? I supposed we could use Jeff's suggestion and go with something like Subtext 2007, followed by Subtext 2007 (June), etc... but that just feel dirty to me.
Ok... how about Service Packs?
One idea that Phil and I have been tossing around is starting with Subtext 2.0 use just the major and minor version numbers for the name. And then we could use the "Service Pack" designation for those in between releases. If we were to retroactively apply this convention to the Subtext v1.9.x family we would have the following lineup:
- Subtext 1.9 "Daedelus"
- Subtext 1.9 Service Pack 1 "Shields Up"
- Subtext 1.9 Service Pack 2 "Repair Job"
- Subtext 1.9 Service Pack 3 "Windward"
- Subtext 2.0 "Poseidon"
- Subtext 2.1 "Red October"
I'm not sure I'm totally sold on this idea either. Maybe it would be better to just stick with the Major version number, and then have each minor version release be a Service Pack. But then what do we call something like the 1.9.4 release?
At any rate, I think that the Service Pack idea is an improvement over our current process/convention.
Ideas, suggestions?
So I'm interested to know, what ideas and/or suggestions do you all have for the versioning and naming of products with short release schedules like Subtext? Do you have any specific examples that have worked - or failed - that you can share?