New version naming standard
The solution is to replace the existing standard with one a simpler and slightly clearer one.
| 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:
| 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.0or greater (as you may have already started revision controlling while proposing it)
Bug fix only Releases
-
in pre stable - you can either increase
y(inx.y) orz(inx.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.