Getting software version numbers right. v1.0.0.1 [closed]

Answer 1

In the github world, it has become popular to follow Tom Preston-Werner's "semver" spec for version numbers.

From http://semver.org/ :

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes. Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

Answer 2

Its all really subjective at the end of the day and simply up to yourself/your team.

Just take a look at all the answers already - all very different.

Personally I use Major.Minor.*.* - Where Visual Studio fills in the revison/build number automatically. This is used where I work too.

Answer 3

For in-house development, we use the following format.

[Program #] . [Year] . [Month] . [Release # of this app within the month]

For example, if I'm releasing application # 15 today, and it's the third update this month, then my version # will be

15.2008.9.3

It's totally non-standard, but it is useful for us.

Answer 4

I think there are two ways to answer this question, and they are not entirely complimentary.

1. Technical: Increment versions based on technical tasks. Example: D is build number, C is Iteration, B is a minor release, A is a major release. Defining minor and major releases is really subjective, but could be related things like changes to underlying architecture.
2. Marketing: Increment versions based on how many "new" or "useful" features are being provided to your customers. You may also tie the version numbers to an update policy...Changes to A require the user to purchase an upgrade license, whereas other changes do not.

The bottom line, I think, is finding a model that works for you and your customers. I've seen some cases where even versions are public releases, and odd versions are considered beta, or dev releases. I've seen some products which ignore C and D all together.

Then there is the example from Micrsoft, where the only rational explanation to the version numbers for the .Net Framework is that Marketing was involved.

Answer 5

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 6

I like Year.Month.Day. So, v2009.6.8 would be the "version" of this post. It is impossible to duplicate (reasonably) and it very clear when something is a newer release. You could also drop the decimals and make it v20090608.