Best Practice: Software Versioning [closed]

Answer 1

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

Answer 2

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)

Answer 3

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.

Answer 4

I would use x.y.z kind of versioning

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

Answer 5

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)

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