version naming

Current Versioning Method The current status quo is that version names should follow the progression defined by the version_compare() function. New Versioning Method Note that the version number is not the same as the version name. The version name is the final name of a version which consists of the version number and an optional postfix. See the following for details. To determine the version name of a release use the following rule set: * A version number must include a major, a minor and optionally a patch level version number. * A package version has a "state" which describes the maturity. The state may be one of "dev", "alpha", "beta", "RC" or "stable" (listed in the order of code maturity). * A backwards-compatability break may include feature additions * A feature addition may include bug fixes * The version name is always computed on the version name of the release on which the new release is based if one exists. * The version number must be greater or equal than 0.1 * All releases of the state "dev", "alpha" and "beta" prior to the first stable release should have a version number below "1.0.0". * The first release with state "RC" and "stable" must have a version number of "1.0". * There may not be a stable release unless there has been at least one release before with the same major version. * BC may only be broken in releases that have a version number of "x.0" with a state lower than stable or that have a version number below "1.0". As a converse only releases that break BC or that have a version number of "1.0" may increase the major version number compared to the previous release. * Features may only be added in releases that have a version number of "x.y" (where "y > 0"). As a converse the minor version may only be increased in releases that add features. * For releases that only fix bugs the version number should be "x.y.z" (where "z > 0") unless the maturity state is increased. As a converse the patch level number should only be used in releases that only fix bugs. * The state should always be added as a postfix unless the state is "stable". The postfix consists of the state followed by a number which is incremented with every subsequent release with the same state. * In the lifecycle of a package each major version increase it is only once (once from major version number 0 to 1, from 1 to 2 etc.). Example Lifecycle of package Foo: 1. development release - initial release - 0.1dev1 (initial version) 2. development release - features added - 0.2dev1 - devel (BC break allowed) 3. alpha release - features added - 0.9alpha1 (BC break allowed - but discouraged) 4. beta release - bug fixes - 0.9beta1 (BC break allowed - but discouraged) 5. beta release - bug fixes - 0.9beta2 (BC break allowed - but discouraged) 6. RC release - bug fixes - 1.0RC1 (BC break allowed - but heavily discouraged) 7. stable release - no changes - 1.0 (BC break is not allowed) 8. stable release - bug fixes - 1.0.1 (BC break is not allowed) 9. development release - features added - 1.1dev1 (BC break is not allowed) 10. beta release - bug fixes - 1.1beta1 (BC break is not allowed) 11. stable release - bug fixes - 1.1 (BC break is not allowed) 12. stable release - features added - 1.2 (BC break is not allowed) 13. development release - major changes - 2.0dev1 (BC break is allowed) 14. alpha release - major changes - 2.0alpha1 (BC break is allowed - but discouraged) 15. beta release - bug fixes - 2.0beta1 (BC break is allowed - but discouraged) 16. RC release - features added - 2.0RC1 (BC break is allowed - but heavily discouraged) 17. RC release - bug fixes - 2.0RC2 (BC break is allowed - but heavily discouraged) 18. stable release - bug fixes - 2.0 (BC break is not allowed) 19. stable release - bug fixes - 2.0.1 (BC break is not allowed) Automation It should be possible to turn this rule set into a little tool which can compute the next version for you based on questions you answer (like is this the first release, did this release break BC?, what state should this release have etc.) This should make it possible to generate correct version numbers without going through this rather lengthy list. Here is a sample implementation: http://www.backendmedia.com/PEAR/version_generator.phps Lukas Smith smith@backendmedia.com _______________________________ BackendMedia www.backendmedia.com berlin@backendmedia.com Linn Zwoch Smith GbR Pariser Str. 44 D-10707 Berlin Tel +49 30 83 22 50 00 Fax +49 30 83 22 50 07