[blank_program]

Recently I was working on a small application and had a question about what some good practices for version numbering are.

How I see it:
Major - large code changes or numerous added features
Minor - small features added or code changes
Revision number - code refined or replaced

I don't want to adopt a Google style of version numbers where they increment major version allt he time so i was curious what you all thought each number should represent.

[tlhIn`toq]

I stick with the system built in to Visual Studio.

[DimitriV]

1.0.0.0 ---------rarely use — bug fixes or spell correction or something like that
| .\. \_______minor update number
| ..\________ revision number 1 (large updates)
|
The 1 for me is major number

[blank_program]

tlhIn`toq, on 02 January 2012 - 04:55 PM, said:

I stick with the system built in to Visual Studio.

version numbers.jpg

If I recall right though VS2010 doesn't increment the number on its own which is sort of where I was going with this. The break down I normally see is: major.minor.revision so I was curious what should be considered before incrementing each.

[jon.kiparsky]

I love the Knuth method: the first version is version 3. Second is 3.1, then 3.14, and so on.
It nicely captures the endless progression towards an unreachable perfection.
But this might not work for you...

It sounds like you've got the general idea of how version numbering is typically done. What exactly release numbers mean is up to you to define. I'd only suggest that you figure this out ahead of time, and make the numbers actually mean something beyond "This is where we fell asleep, and it worked in the morning so we decided to call it a new release". Figure out what sorts of things you want a version number to communicate, and come up with a system that communicates that.

That being said, you might want to consider using version numbers as a road map for future development, not just to mark releases after they happen. Start with version 0.1, which can be more or less "Hello, World" with some bells and whistles, and work out what features would be in a releasable version (1.0) and then assign the features to minor versions between 0.1 and 1.0. This way, you know what you can expect to have at any given stage which should keep you pretty well on track, doing the right things at the right times.