Proposal for "VersionNaming"

» Metadata » Status
  • Category: RFC
  • Proposer: Alan Knowles 
  • License: Creative Commons
» Description
RFC Version Naming
------------------------
Version 2


As discussed previously on pear-group, where a full consensus could not
be reached on the version naming standard, below is the proposed
replacement RFC, which attempts to address the issues.

The issue
-----------
Pear-group announced a versioning naming standard which unfortunatly failed to
explain the reasons behind the decisions made. The aim of the previous standard was

* formalize the version naming of packages.
* fix problems with version_compare going from 1.0RC1 to 1.0.1
* to introduce a rule stating 'no-stable releases before 1.0'
* Solve release naming for My_Package2 (second releases)

It also attemtped to introduce a number of more controversial ideas
* Make the package status more visible.

The last one did not result in a complete consensus, and patches have now been made
to the packager and installer to add state to the filename, output when installing
a package.


The Solution
---------------
To replace the existing standard with one a simpler and slightly clearer one.

My_Package
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)

My_Package2 (the next major version - see major package naming document
for this)
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)

Notes:

* Deliberatly Breaking BC on packages
....o May only be done:
............+ within the 0.*.* series
............+ moving from Major Package Versions (eg. to My_Package2)
* First Releases
....o should not be marked as stable
....o should use 0.1.0 or greater (as you may have already started
........revision controlling while proposing it)
* Bug fix only Releases
....o 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
.... o 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)
....o 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
....o 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)
....o RC releases are strongly recommended for larger, popular packages
....o 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
........o at present this is left to the maintainer to define (using common
............sense), the exact definition should be defined later by
............future RFC's

Changelog
--------------------
Version 1
- General discussion on pear-group indicated that no complete agreement could
be reached on the 2 controversial points (RC/package state suffixes.), as a
result, the conclusion is that they should be proposed as seperate RFC's.
- Deleted discussion notes on the RC/package suffix notes.
- Added note that this document does not officially define BC issues.

Version 2
- Removed RC reasoning justification for x.y.z
- Based on overwhelming straw poll result on pear-dev, adding in x.y.z requirement.

Comments
--------------------
Stig - attempted to define BC, (I've added a note indicating that this should be
defined elsewhere, and that common sense previals in the meantime..)
Lukas - full x.y.z (added), removed note about RC's being justification for x.y.z.
that was not correct (actually it makes sorting releases in ls easier..)


Actions Required
--------------------
Previous Version Naming standard should be marked propenently 'superseeded'
No action will be taken if a package follows one set of rules but not
the other.. 'thats life'....
» Dependencies » Links
» Timeline » Changelog
  • First Draft: 2004-04-29
  • Proposal: 2004-04-29
  • Call for Votes: 2004-11-21