Best Practice: Software Versioning

RoflcoptrException picture RoflcoptrException · May 19, 2010 · Viewed 173.1k times · Source

Is there any guideline or standard best practice how to version a software you develop in your spare time for fun, but nevertheless will be used by some people? I think it's necessary to version such software so that you know about with version one is talking about (e.g. for bug fixing, support, and so on).

But where do I start the versioning? 0.0.0? or 0.0? And then how to I increment the numbers? major release.minor change? and shouldn't any commit to a version control system be another version? or is this only for versions which are used in a productive manner?

Answer

ChrisF picture ChrisF · May 19, 2010

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).