Deciding on version numbers

Question

DUPLICATE

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

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

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!