How do you know what version number to use?

Question

Here's one I have always wondered about...

Please excuse my naivety, but - How do you decide what version number to name your software?

I assume, when somebody creates a "final" version of an application/program it is version 1.0? - Then, what happens when you update it, how do you decide to call it 1.1 or 1.03 etc etc.

Is this mostly for the developer?

Answer 1

A.B.C.D

• A: 0 when beta, 1 when first release, larger then 1 on almost entire rewrite.
• B: New features added
• C: Bug fixes done
• The revision number of the version control repository

Answer 2

More than likely some one in sales or marketing will decide that they need some buzz. This will determine if the next release is 1.01 or 1.1 or 2.0. Kind of works the same in open source but it tends to tied to a fancy new feature that the team is proud of.

Answer 3

To add to all the explanation above, I will suggest use a versioning scheme which, will be easy for your customers to remember and easy for you to baseline and manage your software versions. Also, if you are supporting different framework such as .Net 1.0, .Net1.1 etc, then make sure your versioning scheme takes care of that also.

Answer 4

In the case of a library, the version number tells you about the level of compatibility between two releases, and thus how difficult an upgrade will be.

A bug fix release needs to preserve binary, source, and serialization compatibility.

Minor releases mean different things to different projects, but usually they don't need to preserve source compatibility.

Major version numbers can break all three forms.

I wrote more about the rationale here.

Answer 5

We assign each build of any application unique four part version number defined as Major.Minor.Maintenance.Build.

Major - The Major number is associated with significant changes to the application. This number also determines compatibility with other applications in the same "suite". This number is incremented when new releases are made. This usually means major architectural changes have taken place.

Minor - The Minor number is associated with new functionality and breaking bug fixes. Any time new functionality is introduced or when a breaking bug fix is applied, this number will be advanced and the Maintenance number will be set to zero.

Maintenance - The Maintenance number is associated with non-breaking bug fixes. This number will be advanced whenever a release is made that contains only non-break bug fixes.

Build - The Build number is associated with the subversion changeset (revision number) from which the application was compiled. This will provide an easy way of matching the version number to a precise set of code in subversion.

The only number the developers are really interested in this scheme is the Build. number. By tying the Build number to the subversion revision number we can guarantee what code was used to create the released application.

Answer 6

It depends on the project. below is haskell's package versioning policy.

-- The package version.  See the Haskell package versioning policy (PVP) 
-- for standards guiding when and how versions should be incremented.
-- http://www.haskell.org/haskellwiki/Package_versioning_policy
-- PVP summary:      +-+------- breaking API changes
--                   | | +----- non-breaking API additions
--                   | | | +--- code changes with no API change
version:             0.1.0.0