rfc:peclversioning

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Next revisionBoth sides next revision
rfc:peclversioning [2008/04/02 15:22] pajoyerfc:peclversioning [2008/04/02 15:51] – old revision restored sfox
Line 37: Line 37:
 === Optional Extras === === Optional Extras ===
  
-The cvs $Revision$ or $Id$ placeholder (or any other revision control placeholders) may be used in PHP_MINFO(), but cannot replace the version number.+The cvs $Revision$ or $Id$ placeholder may be used in PHP_MINFO(), but cannot replace the version number.
  
 === Version Naming === === Version Naming ===
Line 48: Line 48:
 The vast majority of PECL packages fall into the 'normal' category. The basic guidelines for these are: The vast majority of PECL packages fall into the 'normal' category. The basic guidelines for these are:
  
-    * A version string **must** include a major, a minor and a patch level number (x.y.zPlease note that all are version numbers are mandatory. +    * A version string **must** include a major, a minor and a patch level number (x.x.x
-    * A package version has a "state" (as indicated in the package.xml file), which describes the maturity. The state may be one of "alpha", "beta", "RC" or "stable" (listed in the order of code maturity). Please note that the state "RC" is achieved by using the state "beta" and appending the version number with "RC" followed by an integer +    * The status of the package may be described using 'a', 'b' or 'RC' followed by a numeric value, e.g. '1.2.1b3', '1.0.0RC2', '1.1.0a1' 
-    * The state should always be added as a suffix unless the state is "stable" 'a', 'b' or 'RC' (respectively for alpha, beta and release candidate) followed by a numeric value. E.g. '1.2.1b3', '1.0.0RC2', '1.1.0a1' +    * //Note that the PEAR installer cannot recognize hyphens in a package version string// 
-        * //Note that the PEAR installer cannot recognize hyphens in a package version string// +    * In package.xml, the 'status' field for a release may be any of "dev", "alpha", "beta" or "stable". These states should be reflected in the version number: a "stable" release should be at least 1.0.0, for example. A Release Candidate is signified by RCx in the version number and a "beta" status in package.xml.
-    * In package.xml, the 'status' field for a release may be any of "alpha", "beta" or "stable". These states should be reflected in the version number: a "stable" release should be at least 1.0.0, for example. A Release Candidate is signified by RCx in the version number and a "beta" status in package.xml. +
- +
-The following points can be added to extend this RFC to fit some basic needs requested by our users or 3rd party. The main goal is to define when a package can break the backward compatibility, add features. There is no technical restrictions or requirements, these points only define how to choose a version number according to the changes done in the release. +
- +
-//Please note that these points are subject to discussions as some developers may not like to be forced to use a given version number. Please mention your preference in your vote or feedbacks/comments // +
- +
-    * 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.0 +
-    * All initial releases of a package with states "alpha", or "beta" prior to the first stable release should have a version number less than "1.0.0". That obviously does not apply to existing packages moving to PECL (from sourceforge or a private repository) and already had stable releases. However the very first release in pear should be beta to prevent issues with the possible errors due to the move +
-    * The first release with state "RC" or "stable" must have a version number of "1.0.0" (does not apply to existing packages with stable releases and version lower than "1.0.0"+
-    * BC may only be broken in releases that have a version number of "x.0.0" with a state lower than stable or that have a version number below "1.0.0". As a converse only releases that break BC or that have a version number of "1.0.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.0" (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 (as in non zero) in releases that only fix bugs. +
-    * The state should always be added as a suffix unless the state is "stable" (please note that as stated above the state "beta" is used for beta releases and for release candidates). The suffix 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 a package == +
-^ Release type ^ Changes ^ Version ^ Notes ^ +
-| development release | initial release | 0.1.0a1 | initial version | +
-| development release | features added | 0.2.0a1 | BC break allowed | +
-| alpha release | features added | 0.9.0a1 | BC break allowed - but discouraged | +
-| beta release | bug fixes | 0.9.0b1 | BC break allowed - but discouraged | +
-| beta release | bug fixes | 0.9.0b2 | BC break allowed - but discouraged |  +
-| RC release | bug fixes | 1.0.0RC1 | BC break allowed - but heavily discouraged | +
-| stable release | no changes | 1.0.0 | BC break is not allowed | +
-| stable release | bug fixes | 1.0.1 | BC break is not allowed | +
-| development release | features added | 1.1.0a1 BC break is not allowed | +
-| beta release | bug fixes | 1.1.0b1 | BC break is not allowed | +
-| stable release | bug fixes | 1.1.0 | BC break is not allowed | +
-| stable release | features added  | 1.2.0 | BC break is not allowed | +
-| development release | major changes | 2.0.0a1 | BC break is allowed | +
-| alpha release | major changes | 2.0.0a1 | BC break is allowed - but discouraged | +
-| beta release | bug fixes | 2.0.0b1 | BC break is allowed - but discouraged | +
-| RC release | features added | 2.0.0RC1 | BC break is allowed - but heavily discouraged | +
-| RC release | bug fixes | 2.0.0RC2 | BC break is allowed - but heavily discouraged | +
-| stable release | bug fixes | 2.0.0 | BC break is not allowed | +
-| stable release | bug fixes | 2.0.1 | BC break is not allowed |+
  
 +If you need further guidance, please refer to the extensive PEAR version naming rules at [[http://pear.php.net/group/docs/20040226-vn.php]]. The one major difference is that PEAR packages don't need to use '-dev' during the development cycle; there are no snapshot releases of PEAR. 'dev' is therefore used as a release tag in PEAR, but not in PECL, where it would be likely to lead to user confusion.
  
 === Core Modules in PECL === === Core Modules in PECL ===
rfc/peclversioning.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1