Best Practice: Software Versioning

You should start with version 1, unless you know that the first version you "release" is incomplete in some way.

As to how you increment the versions, that's up to you, but use the major, minor, build numbering as a guide.

It's not necessary to have every version you commit to source control as another version - you'll soon have a very large version number indeed. You only need to increment the version number (in some way) when you release a new version to the outside world.

So If you make a major change move from version 1.0.0.0 to version 2.0.0.0 (you changed from WinForms to WPF for example). If you make a smaller change move from 1.0.0.0 to 1.1.0.0 (you added support for png files). If you make a minor change then go from 1.0.0.0 to 1.0.1.0 (you fixed some bugs).

If you really want to get detailed use the final number as the build number which would increment for every checkin/commit (but I think that's going too far).

I would use x.y.z kind of versioning

x - major release
y - minor release
z - build number

I basically follow this pattern:

• start from 0.1.0

• when it's ready I branch the code in the source repo, tag 0.1.0 and create the 0.1.0 branch, the head/trunk becomes 0.2.0-snapshot or something similar

• I add new features only to the trunk, but backport fixes to the branch and in time I release from it 0.1.1, 0.1.2, ...

• I declare version 1.0.0 when the product is considered feature complete and doesn't have major shortcomings

• from then on - everyone can decide when to increment the major version...