Getting software version numbers right. v1.0.0.1 [

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 3 years ago.

I distribute software online, and always wonder if there is a proper way to better define version numbers.

Let's assume A.B.C.D in the answers. When do you increase each of the components?

Do you use any other version number tricks such as D mod 2 == 1 means it is an in house release only?

Do you have beta releases with their own version numbers, or do you have beta releases per version number?

Answer 1

I use V.R.M e.g. 2.5.1

V (version) changes are a major rewrite
R (revision) changes are significant new features or bug fixes
M (modification) changes are minor bux fixes (typos, etc)

I sometimes use an SVN commit number on the end too.

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

A good and non-technical scheme just uses the build date in this format:

YYYY.MM.DD.BuildNumber

Where BuildNumber is either a continuous number (changelist) or just starts over at 1 each day.

Examples: 2008.03.24.1 or 2008.03.24.14503

This is mainly for internal releases, public releases would see the version printed as 2008.03 if you don't release more often than once a month. Maintenance releases get flagged as 2008.03a 2008.03b and so on. They should rarely go past "c" but if it does it's a good indicator you need better QA and/or testing procedures.

Version fields that are commonly seen by the user should be printed in a friendly "March 2008" format, reserve the more technical info in the About dialog or log files.

Biggest disadvantage: just compiling the same code on another day might change the version number. But you can avoid this by using the version control changelist as last number and checking against that to determine if the date needs to be changed as well.

Answer 4

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.

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'm starting to like the Year.Release[.Build] convention that some apps (e.g. Perforce) use. Basically it just says the year in which you release, and the sequence within that year. So 2008.1 would be the first version, and if you released another a months or three later, it would go to 2008.2.

The advantage of this scheme is there is no implied "magnitude" of release, where you get into arguments about whether a feature is major enough to warrant a major version increment or not.

An optional extra is to tag on the build number, but that tends to be for internal purposes only (e.g. added to the EXE/DLL so you can inspect the file and ensure the right build is there).