Best Practice: Software Versioning

Question

I couldn't find a similar question here on SO, but if you find one please link.

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 should'nt any commit to a version control system be another version? or is this only for versions which are used in a productive manner?

Answer 1

I would use x.y.z kind of versioning

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

Answer 2

The basic answer is "It depends".

What is your objective in versioning? Many people use version.revision.build and only advertise version.revision to the world as that's a release version rather than a dev version. If you use the check-in 'version' then you'll quickly find that your version numbers become large.

If you are planning your project then I'd increment revision for releases with minor changes and increment version for releases with major changes, bug fixes or functionality/features. If you are offering beta or nightly build type releases then extend the versioning to include the build and increment that with every release.

Still, at the end of the day, it's up to you and it has to make sense to you.

Answer 3

Start with version 3, then add decimal digits from pi until you converge.

Answer 4

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

Answer 5

As Mahesh says: I would use x.y.z kind of versioning

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

you may want to add a datetime, maybe instead of z.

You increment the minor release when you have another release. The major release will probably stay 0 or 1, you change that when you really make major changes (often when your software is at a point where its not backwards compatible with previous releases, or you changed your entire framework)

Answer 6

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

Answer 7

You know you can always check to see what others are doing. Open source software tend to allow access to their repositories. For example you could point your SVN browser to http://svn.doctrine-project.org and take a look at the versioning system used by a real project.

Version numbers, tags, it's all there.

Answer 8

We use a.b.c.d where

• a - major (incremented on delivery to client)
• b - minor (incremented on delivery to client)
• c - revision (incremented on internal releases)
• d - build (incremented by cruise control)

Answer 9

We follow a.b.c approach like:

increament 'a' if there is some major changes happened in application. Like we upgrade .NET 1.1 application to .NET 3.5

increament 'b' if there is some minor changes like any new CR or Enhancement is implemented.

increament 'c' if there is some defects fixes in the code.