When to increase software version number from 1.x to 2.x? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 11 years ago.

I know there are a lot of thoughts about how to use (or even use) software versioning. Even though I would like to know when a software version should become 2.x after being 1.x.

In my example I use 1 and 2, but it could have been any other digit of course.

Is it after a complete rewrite? Or a new/mostly renewed User Interface? A bunch of new (major) features? After a rewrite of the program its 'core'?

When I look to (probably a bad example) Internet Explorer or Chrome I cannot really tell why they have increased their 'major' version so rapidly...

My idea at this moment is that when a program goes from 1.x to 2.x, it should be completely rewritten with at least the same features, only better (more stable, optimized, cleaner code, etc.)

Any tho开发者_Python百科ughts?

---

Ultimately, anything we develop is for someone or something to use. When something is being used, and has the ability to change, whomever is using it usually wants to know when things change and how much they change so that they can be ready for anything breaking regarding how they are using it.

To this end, the goal of a version number is to quickly determine the scope of the differences between two versions of something (in this case, two versions of a software project).

To summarize so far:

1. Everything we develop changes over time
2. Everything we develop is so someone else can use it
3. The users care about those changes, since it might break their things
4. The users need a quick way to determine if a new version will or will not break their things

Points 2 - 4 tell us that our software should have a well defined external interface (API), and that the versioning system for our software should indicate when the external interface changes, since that's what other people use.

The Semantic Versioning project details a specification for exactly how this should be done. I won't rehash everything in the specification (really though, it isn't very long), but here's the main points:

1. Version numbers are in the form X.Y.Z
   • X is the Major version
   • Y is the Minor version
   • Z is the Patch version
2. The Patch version (Z) is incremented for backwards-compatible bug fixes
3. The Minor version (Y) is incremented for new, backwards-compatible functionality is introduced to the API
4. The Major version (X) is incremented for backwards-incompatible changes

There are a few more details in the specification, as well as additional justification and rationale, but those are the main points.

In the end, all a version number does is give a structured way to indicate change to other entities that use the software. As long as you are meeting their needs and are consistent, any versioning scheme is fine.

---

Normally such a version change would indicate a major change in functionality.

The rule(s) of thumb I tend to use are:

1.0 - 2.0 (major change, a significant amount of additional or modified functionality)
1.0 - 1.1 (minor change, some additional or modified functionality)
1.0 - 1.0.1 (bug fix or other minor patch, no change in core functionality)

There are several different schemes you can follow that are listed at http://en.wikipedia.org/wiki/Software_versioning

---

It's all up to you, really.

Some software, like OpenSSL just hit 1.0 after years of development, while browser software like FireFox and IE seem to be releasing major versions very often.

It's a matter of taste.