Best Practice: Software Versioning [closed]

Question

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

I use this rule for my applications:

x.y.z

Where:

• x = main version number, 1-~.
• y = feature number, 0-9. Increase this number if the change contains new features with or without bug fixes.
• z = hotfix number, 0-~. Increase this number if the change only contains bug fixes.

Example:

• For new application, the version number starts with 1.0.0.
• If the new version contains only bug fixes, increase the hotfix number so the version number will be 1.0.1.
• If the new version contains new features with or without bug fixes, increase the feature number and reset the hotfix number to zero so the version number will be 1.1.0. If the feature number reaches 9, increase the main version number and reset the feature and hotfix number to zero (2.0.0 etc)

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)

Yet another example for the A.B.C approach is the Eclipse Bundle Versioning. Eclipse bundles rather have a fourth segment:

In Eclipse, version numbers are composed of four (4) segments: 3 integers and a string respectively named major.minor.service.qualifier. Each segment captures a different intent:

• the major segment indicates breakage in the API
• the minor segment indicates "externally visible" changes
• the service segment indicates bug fixes and the change of development stream
• the qualifier segment indicates a particular build

There is also the date versioning scheme, eg: YYYY.MM , YY.MM , YYYYMMDD

It is quite informative because a first look gives an impression about the release date. But i prefer the x.y.z scheme, because i always want to know a product's exact point in its life cycle (Major.minor.release)