New version naming standard

The solution is to replace the existing standard with one a simpler and slightly clearer one.

MyPackage versions
Version	Description
`0.1.0` ... `0.1335.0`	initial pre-stable releases (bug fix releases increment .z eg. `0.12.1` )
`1.0.0`	first stable release
`1.1.0`	first feature upgrade
`1.1.1`	bug fixes on feature upgrade

The next major version is MyPackage2:

MyPackage2 versions
Version	Description
`0.1.0` ... `0.1335.0`	initial pre-stable releases (bug fix releases increment .z eg. `0.12.1` )
`2.0.0`	first stable release
`2.1.0`	first feature upgrade
`2.1.1`	bug fixes on feature upgrade

Deliberatly Breaking BC on packages

Breaking BC may only be done:

within the 0.*.* series
moving from Major Package Versions (eg. to My_Package2)

First Releases

should not be marked as stable
should use 0.1.0 or greater (as you may have already started revision controlling while proposing it)

Bug fix only Releases

in pre stable - you can either increase y (in x.y) or z (in x.y.z), for example
- 0.2.0 -> 0.3.0
- 0.2.0 -> 0.2.1
after a stable release
- 1.3.0 -> 1.3.1
- 2.4.0 -> 2.4.1

Feature addition Releases (that may also include bug fixes)

Should just increment the y (in x.y), for examples

0.3.0 -> 0.4.0
1.3.0 -> 1.4.0
2.10.0 -> 2.11.0

Stable Releases

You should never release stable packages with a 0.x format (this is a common situation at present, and is the only significant change that is being proposed.)

Appending RC releases (Release Candidates)

RC releases are strongly recommended for larger, popular packages.

If you intend to append RC releases to your package, you should append a release number to after the RC, for example:

0.123.0 -> 1.0.0RC1
1.0.0RC1 -> 1.0.0RC2
1.0.0RC2 -> 1.0.0
1.0.0 -> 1.0.1

Defining BC breaks

At present this is left to the maintainer to define (using common sense), the exact definition should be defined later by future RFCs.