Deciding on version numbers

Question

DUPLICATE

How to do version numbers?

---

Hello,

So I recently saw that Groovy was released to version 1.6

Answer 1

They're very much arbitrary. A lot of people like to have something like

[major].[minor].[release].[revision]

as their versioning scheme, but I've also been in companies that refused to release a 1.0 branded product because one of the VPs didn't want to. Marketing also can influence this.

A good question to ask for increasing the major version can be:

If this were a paid product, would customers pay to upgrade to this newer version?

If so, it might be good increase the major number.

Answer 2

Version numbers are arbitary, but there are some rules fo thumb (I think). Very minor changes or bugfixes usualy increase by 0.0.1, ie V1 becomes V1.0.1. Minor changes to functionality increases by 0.1.0 i.e V1.0.1 becomes V1.1.0. Major changes or re-writes get an increase of 1.0.0, i.e to V2.

That said, lot's of companies seem to try to convince customers something is major by going up by 1.0.0 when similar changes have been 0.1.0. Also, some companies who rely on support contracts will give out 0.1.0 updates for free, but charge for 1.0.0 updates.

Also, IIRC, some projects tend to signify experimental builds with odd versions and stable builds as even ones, (so V3 is dangerous, V4 is stable).

Answer 3

Distinguish between versioning for marketing and versioning for technical use.

For marketing, the answer is: "Whatever you want your customers to think." In that case, a "major new version" should probably be accompanied by a major version number.

Also be aware that careful customers will be hesitant to use "major" new releases until time has passed and they've tried it in a test environment. A "build change" release is perceived as having bug fixes and other minor things that don't require much process to install.

For technical use, the answer is: "Whatever information you want to encode for developers." There's no one correct way to do this; it depends on your goals.

Perhaps a "major" version means "significant changes that might mean lots of new bugs." Perhaps a new "build" number happens on every single compile. Perhaps nightly build tags by date are your version. You can base it on time, Scrum cycles, milestones, features, whatever!

Answer 4

MajorRelease.MinorRelease.Hotfix

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.