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.