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

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

People tend to want to make this much harder than it really needs to be. If your product has only a single long-lived branch, just name successive versions by their build number. If you've got some kind of "minor bug fixes are free, but you have to pay for major new versions", then use 1.0, 1.1 ... 1.n, 2.0, 2.1... etc.

If you can't immediately figure out what the A,B,C, and D in your example are, then you obviously don't need them.

Answer 3

The only use I have ever made of the version number was so that a customer could tell me they're using version 2.5.1.0 or whatever.

My only rule is designed to minimize mistakes in reporting that number: all four numbers have to be 1 digit only.

1.1.2.3

is ok, but

1.0.1.23

is not. Customers are likely to report both numbers (verbally, at least) as "one-one-two-three".

Auto-incrementing build numbers often results in version numbers like

1.0.1.12537

which doesn't really help, either.

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.