Versioning Convention

[Bayu Ardianto]

I see lot's of software with version numbers. Are there any international versioning conventions for software.
eg. 1.2.0.1
what 1, 2, 0, 1 or any digit mentioned there means?

[Ejaz]

[ Moved Thread ]

[Ejaz]

Well, usually there are two types of version numbers.

1) Major Version
2) Minor Version

For example, in 2.6 , 2 is the major version and 6 is the minor version. It can be further expand as 2.6.1, 2.6.2. This means that 2.6.2 has minor updations in it as compare to 2.6.1. But for 3.0 means, its a new version in itself.

The formal documentation of the particular software may give you more details if they have associated any other concept with the version numbers as well.

[Pinky98]

I see lot's of software with version numbers. Are there any international versioning conventions for software.
eg. 1.2.0.1
what 1, 2, 0, 1 or any digit mentioned there means?
A widely accepted version convention is:

Major.Minor.VMinor.Build

Major - Version numbers with matching major version numbers should be fully compatible with each other. New features which will render a verion incompatiable (either forward or backward) should then be a new MAJOR version number.

Minor - Each time a new feature is added or the look/feel of the app is changed the minor version should be changed.

VMinor - Used to track bug fixes. If you release a new version of your app, but then a few months later release it with several bug fixes (no new features or change to look/feel) then the VMinor field is changed.

Build - The build number of the app. Mainly used for internal version tracking. Unless one does a complete re-code of the app, this is almost never reset to 0, but simply keeps increasing.

[Andreas Masur]

A widely accepted version convention is:

Major.Minor.VMinor.Build

Which usually is referred to as

Major.Minor.PatchLevel.Build

This scheme is very popular in the Open Source scene...

[Latem]

Also sometimes the "minor" part has added significance that indicates the state of the release. This is usually in open source projects. For example in the Linux kernel, even numbers indicate a stable release, i.e. one that is deemed fit for production use, such as 1.2, 2.4 or 2.6. Odd numbers are development releases, such as 1.1 or 2.5. They are for testing new features and drivers until they become sufficiently stable to be included in a stable release.

Latem

[Bayu Ardianto]

gosh, thanks for the replies..., i thought it wouldn't be that much... :)

now, if 2.3.1.7 and the last digit (7) is bulid digit. Does it mean i have pressed F7 at VC++ IDE 7 Times? :) So if it does, how can i automatically increase the number in my .rc files version info? And what about the other digit? Are there no sucha automated tools to do versioning?

Many thanks for the replies... :)

[Andreas Masur]

now, if 2.3.1.7 and the last digit (7) is bulid digit. Does it mean i have pressed F7 at VC++ IDE 7 Times? :) So if it does, how can i automatically increase the number in my .rc files version info? And what about the other digit? Are there no sucha automated tools to do versioning?
Well..unfortunately it doesn't work like that...

How to increment version information after each build in Visual C++ (http://support.microsoft.com/kb/q237870/)