Can I have some version numbering advice?

Question

Our product has a long history (12 years or so).

It's origins are in VB3 (Version 1) and later VB6 (Version 2). (Version numbers were a "dogs breakfast" and version control was a nightmare.

I've been involved here for a couple of years now. We have Version 3 in development on the .Net platform but version 2 continues to be supported with periodic releases - about 3 or 4 per year.

I introduced nightly automated builds back when I started and the version number of our product was 2.2.2. Everyone was planning on just releasing 2.2.3, but the automated build process and VB6's "interesting" 3 part numbering system, meant we need to make use of the third portion - build / revision number - which ever it is supposed to be.

So we released version 2.3 (with a build number of "whatever") and went to work on 2.4 (incrementing build numbers nightly), then 2.5, then 2.6 etc.

The build number was hidden away from public view but available for support purposes even though we rarely release more than one build of a version - we have needed to patch occasionally though.

Consistency ensured. Now we reach 2.9. We are about to move to 2.10 (Two point nine, up to Two point Ten). Unfortunately non-technical guys are reading this like a rational number (Two - point One). They can't understand why we don't just go to Version 3.0 - like counting. (The build number is only displayed on the "Help/About" screen for support purposes).

I don't think a product (major number) upgrade is warranted especially due to the expectations this will set in the market place.

Is there a correct way to proceed here? (2.10 or 3.0 or something better - or does it even matter?)

(NB. I've gone to some lengths to ensure the version number now displays as 2.09, instead of 2.9 (on our web site, the product splash screen and various other public places etc), so that when we move to 2.10 it may make more sense, but this is potentially just as confusing because 2.09 is really a lower rational number than 2.8...)

See Also:

Deciding on version numbers

How to do version numbers?

How do you know what version number to use?

Answer 1

You could do 2.9.1 or even 2.10.1 but there are many projects that keep counting. 2.10, 2.11 12 13 etc.

Answer 2

How you version your own software is up to you. There is no "right" or "wrong", apart from what's best after considering maintenance, release-management and customer-support points of view. The important thing is for you to control the versioning--that you understand it, that everyone who works with the product understands it, and that it doesn't cause problems later. There is no meaning to going from 2.9 to 2.10 as opposed to 3.0 except the meaning you give to it.

Answer 3

I think you pursued the correct approach by going towards 2.10. The primary purpose of version numbers should be the grouping of new features and development into definable released versions. If your numbering is getting in the way of this, you need a different numbering scheme.

Answer 4

If 2.10 causes confusion then skip it and go to 2.11. Get ready for the same problem with 2.20 though :)

Answer 5

Look at it as a chance for the non-technical guys to learn something ;-) Version numbers should be like chapter and section numbers in a book, they split the lifetime of your program into coherent and internally consistent blocks.

Answer 6

I would suggest to always use at least 3 components in your version numbers, and don't hide anything but the forth or further components. Stick to that convention everywhere, because it makes obvious to non-technical people that that can't be a rational number, it has to be something else (that is, a compound of three integers).

• 2.8.0
• 2.9.0
• 2.10.0
• 2.11.0
• ...

Also, in about dialogs, stick the build date (yyyy-mm-dd) near the version number. If the customer is confused with the version numbers, he/she can just compare the dates, that is far more intuitive for normal people.

Answer 7

I recommend decoupling your marketing version from the internal versions of you DLLs and whatnot. They have different semantics.

Answer 8

Wikipedia has very good article on software versioning

If you are working on long on-going project, sequence-based identifiers (like 1.0, 2.0 etc) don't scale.

I personally like (and prefer) Ubuntu versioning scheme which is using year and month of release in its version. Ubuntu 8.04, for example, was released April 2008.

Answer 9

Thanks - there are so many great answers here.

I'm having "accept an answer anxiety" - but I think it's probably right to take a bit from each answer.

Firstly, there is no right or wrong here. Secondly, numbering shouldn't get in the way of anything.

Version numbering can be thought of like chapters and section numbers in a book - which will really help me explain to others, the way I'm thinking at least.

Separate / decouple the marketing versioning from the technical / development version numbering would solve everything...this is a longer term answer though.

I'm sticking with 2.10 to follow 2.9 - and I'll battle on...and definitely investigate Ubuntu

Answer 10

The other answers are only half right. Version numbers have the meaning you give them, but they also have the meaning others give them. Your own meaning really doesn't matter since you're not going to be there to correct your users. If they think that going from 2.9 to 3.0 is a huge jump, then that's how they'll take it. If they're afraid of using x.0 versions, then they won't. If they're used to odd numbered releases being alphas, then they won't use those.

As much as I'd hate to say it, version numbers are a marketing tool. They say something to the user about the release, so you must take that into account when choosing your version numbers.

Problem is, version numbers mean different things to different people. There are some things you can predict. As I mentioned above, people will be suspect of x.0 releases. They'll expect big changes for 2.x to 3.x. If you want to try to play that came, go ahead.

There are two essential attributes of version numbers. First, they must always go up. Second, they must sort easily. The first is obvious, but the second is often violated. Consider version 2.9 -> 2.10. Numerically speaking, 2.9 is greater than 2.10. You must consider them major/minor version numbers in order for it to sort correctly. From this stems the confusion as to whether 2.10 or 3.0 follows 2.9. Even if we know the sorting rules, it still seems wrong. For this reason I always pad my versions. 2.09 is followed by 2.10. It sorts correctly both as a number and as a dotted pair.

That still leaves us with the user trying to divine meaning from the version number, like numerologists sifting through winning lottery numbers. You can try to play that game, or you can leave it. Why use a dotted pair at all? Use an integer. It's unambiguous. It sorts trivially. It gives no false meaning for the user to latch on to.

I can go one better. There is clear meaning you can give to a version number, something that is useful. There's a problem we have in the CPAN world of people not upgrading their modules because they're using version 1.03 and the latest is 1.07 and look, it's only .04 difference. Why bother upgrading? What it doesn't show is that there was four years between 1.03 and 1.07. Microsoft figured that out, that's why we buy Office 2009 instead of Office 12 (it can also bite you in the ass if you don't release often, who would want Windows 98 in 2001?) It's right there in the version number. "Widgets 2007" tells you maybe you should go look for an upgrade.

To that end, I am now using ISO dates as versions. If you released today it would be version 20090309. If you had to release two in one day, tack the hour and minute on the end: 20090309.2051. It sorts easy. It always goes up. It conveys some unambiguous meaning to the user about the release. Here's an example.

Answer 11

You should tell them to brand the version of the software in a way that is independent of the internal version number. For instance, iPhoto '09 is iPhoto version 8.x. Microsoft did the same thing.

Clearly, the major vendors have moved towards a branded version having to do with feature releases while allowing the developers to be freer with their version numbers. This satisfies everybody and the marketing guys will be especially happy because they get to come up with a whole new strategy for how to brand the software releases.