Deciding on version numbers

Question

DUPLICATE

http://stackoverflow.com/questions/615227/how-to-do-version-numbers

---

Hello,

So I recently saw that Groovy was released to version 1.6 and while listening to the Java Posse Podcast they were commenting how there was so much packed into this release it should have been a 2.0 release.

That got me thinking. Are version numbers just arbitrary? I used to think they had a meaning but I guess not. Is it all just milestone based and set project to project?

How does your team control your version numbers and releases?

Thanks in advance

Answer 1

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 2

MajorRelease.MinorRelease.Hotfix

Answer 3

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 4

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.