Yeah, such a thing actually happens. Especially when you are actually writing a product.

Typically, you start off with v0.1, then go up to v0.8, etc. Then someone in marketing decides to call this "version 2.0". And so you change all your constants. Now, if you're relying on the version number to check things (like API availability for plugins) you might want to increase the major revision number some day. Internally, v3.0 might be totally different from the v2.0, and so you want to make a major revision bump.

Well, comes the marketing and wants to name your new version "version 2.0 Gold". Erm. Your fine schemes go totally haywire. Or they want to name it "version 2000". Even worse. The next version might well be called "3.0", "2.1", "2000.1", "2001", "3000", or "XP" for all you know.

This is why I usually keep two version numbers: the release number and the version number.

Release number#

The release number is an internal release number of the form major.minor, where major and minor are integers. This is not a decimal number: 1.1 < 1.3 < 1.10 < 1.12 < 2.0 etc, and it is always monotonically increasing. This is what you use to check for the actual software release.

Version "number"#

This is a freeform string and can be whatever the marketing currently desires. It is only displayed to the user, it is never used anywhere else. No software relies on it. You can add whatever to it. Marketing is happy =).

The only drawback to this scheme is that you have to keep track which versions correspond to which release numbers. But this is relatively trivial, and can be easily put into CVS or your ChangeLog, or Release notes.

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-2) was last changed on 09-Jan-2002 19:17 by jalkanen