Develop Version Numbering for an Application

Question

Firstly, I think this forum is not appropriate for my question, so if it is in wrong place, kindly forgive and place wherever appropriate. I didn\'t find proper forum for my que

Answer 1

Frustratingly, .Net seems to consider build numbers the 'wrong' way round, according to many people. AssemblyInfo specifies build number as [Major][Minor][Build][Revision], which to me doesn't make any sense. Surely a nightly build happens more often than a revision of the spec, and is therefore the 'smallest' change? I'm not going to fight against the framework though, so I'm just going to have to tolerate it.

Maybe it's the same root cause as the phenomenon of Americans specifying dates in the wrong order. Again, common sense would dictate large->small consistently.

With regards to organising this conceptually, I would say that each part of a four-part build number should indicate the most recent change of the appropriate magnitude; i.e:

Major: A major upgrade of the application, which you expect users to pay for if it's a commercial project. Users should expect to face infrastructure concerns, such as service packs and new .Net versions;

Minor: A significant rollup of bug fixes and change requests that would fulfil the description of 'small feature'. Anything that should arguably have been in the program already can be rolled into a minor version;

Build: Personal choice, but for me this would be the unique build number. If you get your binaries from an integration server, this could run into the tens of thousands. Likely to be a nightly build, but could also be built on demand when the PM says 'go'. The build number should uniquely correspond to an event that kicked off a full production build on the integration server.

Revision: Should correspond to an amendment to the specification, at least conceptually. Would typically match an item in the changelog i.e. all incremental changes up to and including change request x.