The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Dilemma on version numbers

I'm using standard version numbers - MajorVersion.MinorVersion.Build.Revision.

When I am working on my first (1.0) release, I number like this:
0.1.x.x, 0.2.x.x and so on, until I have RC1 or Beta or whatever I call my final few versions.

When I release version 1 and start working on bug fixes, I number like this:
1.1.x.x, 1.2.x.x and so on.

Now let's say I want to start version 2.0 which has brand new features. I make a copy of my 1.x.x.x code and then what do I use for the version number? Calling it 2.0.x.x implies I've already finished version 2.0. On the other hand numbering it 1.x.x.x implies it is more bug fixes and minor enhancements of version 1.0.

I know this is a minor issue, but it's driving me crazy.
Praveen Angyan Send private email
Tuesday, August 21, 2007
 
 
call it 0.1.x.x again...?

I think it wouldn't matter much unless you release a lot of pre-version 2.0 builds to the public.

Can you tell us why this is important for you?
Marc Jacobi Send private email
Tuesday, August 21, 2007
 
 
Call it 1.99.x.x. or 1.90.x.x and go up from there to 2.0.
Michael Suess Send private email
Tuesday, August 21, 2007
 
 
We had a similar problem. Our numbering system is 3 digits:

MajorVersion.MinorVersion.BugFixRelease

When we release version 5 to customers, it is:

5.0.0

And any bug fixes to this will be

5.0.1 and so on.

When we are working towards a release, the BugFixNumber starts at 501. So,

5.0.501 = The first release candidate towards 5.0.0.

5.0.502 = The second release candidate towards 5.0.0

5.4.501 = The first release candidate towards 5.4.0.

For us this works fine (We've never needed a RC for a bug fix!)
IanH. Send private email
Tuesday, August 21, 2007
 
 
>> Calling it 2.0.x.x implies I've already finished version 2.0.

You can deal with this ‘problem’ by simply changing your thinking. Calling it 2.0.x.x only implies that you’ve *started* version 2.0. When version 2.0 reaches production quality then, whatever build number is in use at that point is what implies that you’ve *finished* version 2.0.

The .NET Framework version number is an example of this. There, version 2.0.50727 is the version number that implies that Microsoft has *finished* version 2.0. All version numbers prior to that point merely implied that Microsoft had *started* version 2.0.
Mike
Tuesday, August 21, 2007
 
 
Yes, one way to look at it is when you truncate the build number itself, what's left is the final release of that particular version. 2.0.1 is the first build of version 2.0.

It just so happens that the vast majority of your customers won't care what the build number is, but your customer support staff may want to make sure they're not working with a beta or a release candidate.  So in big bold type, you might say this is version 2.0, and in tiny little type in the about-this box, you might say this is version 2.0.734. Customer support can then cross reference the 734 to determine which build they actually have.
TheDavid
Tuesday, August 21, 2007
 
 
Thanks. This is important to me since I've set up a continuous integration server that labels the source code on every build, and I want a system that works. I think the best suggestions are the last two suggestions.
Praveen Angyan Send private email
Tuesday, August 21, 2007
 
 
Beaten to the punch.

I was going to suggest the same thing, but with a slightly different format:

Version 2.1 Build 357
OneMist8k
Wednesday, August 22, 2007
 
 
We've used timestamps quite happily: "2.1 2008/08/24 13:45"
Stan James Send private email
Friday, August 24, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz