Code version change "rules" [closed]

Solution 1:

Version numbering policies can be a bit crazy at times (see Version numbers and JSR277, or Oracle, with its Oracle Database 11g Release 2: 11.2.0.1.0.
See also Software Versioning is Ridiculous).

But you can start by looking et the Eclipse Version Number policy as a good start.
If you really think you need more than three digits, this V.R.M.F. Maintenance Stream Delivery Vehicle terminology explanation is also interesting, but more so for post 1.0 softwares, where fix pack and interim fixes are in order.

1/ "Ship it already": 1.0.0

Also known as the "1.oh-oh" version. At least, it is out there and you can begin to get feedback and iterate fast.

2/ 0.x if major features are still missing; 1.0.0 if the major features are there.

3/ Yes, but I would say only for large projects with a lifespan over several years (a decade usually)

Note that "correctly" (while being described at lenght in Semantic Versioning 2.0.0) can also be guided by more pragmatic factors:

See the announcement for Git 1.9 (Januaury 2014):

A release candidate Git v1.9-rc2 is now available for testing at the usual places.

I've heard rumours that various third-party tools do not like the two-digit version numbers (e.g. "Git 2.0") and started barfing left and right when the users install v1.9-rc1.
While it is tempting to laugh at them for their sloppy assumption, I am also practical and do not mind calling the upcoming release v1.9.0 to help them.

If we go that route (and I am inclined to go that route at this moment), the versioning scheme will be:

• The next release candidate will be v1.9.0-rc3, not v1.9-rc3;

• The first maintenance release for v1.9.0 will be v1.9.1 (and Nth one be v1.9.N); and
• The feature release after v1.9.0 will be either v1.10.0 or v2.0.0, depending on how big the feature jump we are looking at.

Update Feb. 2019: semver itself is about to evolve (again, after semver2).
See "What’s next for SemVer", and semver/semver/CONTRIBUTING.

Solution 2:

At our company, we are using four token versioning concept. It's something like a.b.c.d kind:

(major).(feature).(revision).(bug/refactoring)

It's related with issue types which we use in our development life cycle. We can track what has done or changed between two following versions at a glance. By comparing two following version numbers you can identify number and types of issues done. For more information, full documentation is here.