Hey programmers, anyone given Version Numbering any thought? (1 Viewer)

[Gordon Moore]

This is always a topic of hot debate around our office. No one and I mean NO ONE can accurately define version numbering.
The generaly accepted practise around our office is one similar to GNU:
major.minor.patchlevel
minor (odd numbers are beta even numbers are stable...release).
patchlevel is pretty self explanatory but tell me where the borders between major and minor are???????
This has always bugged me.
Some products use letters, some use only major.minor.
Also, when do you appropriately revert a number to zero?
I've always assumed that when a major version goes up then minor and patchlevel go to 0. If minor increases then patchlevel would automatically be assumed 0.
What do you guys do? Does anyone have a really good handle on this? I'd really like to know.
Questions, questions, questions....please discuss amongst yourselves....

 

[Steven K]

Hey Gordon,

We do the #.#.#.# format... for instance, 2.12.0.0 (major.minor.revision.revision)

From what I've seen this is the most common. Microsoft does all of their DLLs this way.

 

[Gordon Moore]

revision.revision ??? interesting, but how does that work?
I fixed a fix??? Or is it not the literal meaning of revision?
I work with Oracles tools and C for our user-exits (dll). The product is in-house so they came up with their own scheme...but it bugs me that no one really knows what it is.
Anyone have any good definitions of major/minor (and I don't mean chords....piano humour)/revision
revision: what we intended it to be the first time around

 

[WoodyH]

I'm not a programmer, but the way I've always understood it was that a ground-up code reworking (more than 50% of the code is new or changed, additional primary features, etc.) would be a 'major' (X.x.x) revision, less drastic but still noteable changes are a 'minor' (x.X.x) revision (less than 50% of the code new or changed), and bugfixes and patches are the last category (x.x.X).

 

[Iain Lambert]

revision - bug fixes, performance improvements etc. I use the minor revision number for test fixes and incrementals, going to a major revision once I'm happy.

minor - its the new features that revisions have put in place, but they have been bundled up into something worth calling a new release. Fairly big changes can go here, as long as it doesn't break:

major - changes are so big that either (a) backwards compatibility has been broken somehow, or (b) you think the thing is seriously different. As a Microsoft example, you'd update major for a NT4 to 2000 magnitude change, but only a minor for '98 to '98SR2.

All this is made up off my head though, not hard and fast rules. Sometimes (mumble Ghost mumble) major just means 'we the vendor have taken the opportunity of a new Microsoft release to change the licensing method. Please give us money to get the product working again'.

 

[JasG]

Version number meanings are all over the map, even at MS. After much pain and suffering, I settled on the following:
major.minor.build.patch
I reset patch to zero as I increment build.
I reset minor to zero as I increment major.
Build can be an increasing number, a date whatever - as long as it never decreases.
The key is to keep increasing the number (which is actually stored as a pair of DWORDs). If you mess that up, installation can become nightmare. A good installer will never replace a higher numbered file with a lower numbered one. So, if your new file has a lower version, sorry...
The link below describes more than you would ever want to know.... FYI, there are FOUR version numbers defined for each file: Product, File/Module and string versions of each.
For 'string version' numbers, I NEVER use '5.00.0120.0' since neither 'string' or 'numeric' versions are decimal numbers and leading zeroes are meaningless.
Link Removed
OS version numbers are more complex with the concept of a service pack added to the mix.

 

[Steven K]

What JasG has stated is actually what we do as well. Jas, you said that each number is a pair of DWORDS? I take it, a high order DWORD and a low order DWORD?

And speaking of DWORD, let's all take the time to thank Microsoft for implementing non-portable type-defines like DWORD, UINT, and TCHAR... OK, I have to thank them for TCHAR... makes switching from ASCIIMBCS builds to Unicode builds a snap.

BTW: Does anyone know if XP has native Unicode support like NT and 2K does? I'm thinking that it does, as it is based on the same kernel.

One more thing: Unicode text files saved under notepad and other Windows apps have an 0xFEFF character attached to the beginning of the file. I have not seen this behavior on other platforms, and nobody at work can provide a definite answer as to whether this is a standard or not... probably a Microsoft standard.