rfc:peclversioning
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
rfc:peclversioning [2008/04/02 15:47] – sfox | rfc:peclversioning [2008/04/02 16:05] – pajoye | ||
---|---|---|---|
Line 1: | Line 1: | ||
===== Request for Comments: PECL Versioning ===== | ===== Request for Comments: PECL Versioning ===== | ||
- | * **Author:** Pierre A. Joye | ||
- | * **Status:** Work in progress | ||
=== The Problem === | === The Problem === | ||
Currently, PECL versioning is fairly anarchic. It is impossible to determine the status of an extension, or whether an update will break binary compatibility with previous versions (or work with a given PHP release) without a long try-& | Currently, PECL versioning is fairly anarchic. It is impossible to determine the status of an extension, or whether an update will break binary compatibility with previous versions (or work with a given PHP release) without a long try-& | ||
- | === Some Facts and Figures === | + | There is actually two RFCs (proposals) to deal with version number |
- | There are currently 214 modules | + | |
- | * 1 is written in PHP | + | * [[peclversioning/ |
- | * 3 are SAPIs | + | * [[peclversioning/ |
- | * 2 are no longer hosted in PECL (and should be deleted) | + | |
- | * 1 doesn' | + | |
- | * 1 doesn' | + | |
- | * 1 was a CVS error (and should be deleted) | + | |
- | * 1 is the timezone library for ext/date, and probably has non-standard versioning requirements | + | |
- | Of the remaining 204: | ||
- | |||
- | * 13 already use PHP_EXTNAME_VERSION declared in php_extname.h, | ||
- | * 25 already declare and use a versioning macro in php_extname.h, | ||
- | * 27 already declare and use a versioning macro somewhere in the source | ||
- | * 3 do the whole thing in reverse and use the release version from package.xml | ||
- | * 136 either hard-code the version, use $Id alone, use $Revision alone or ignore the whole thing | ||
- | |||
- | === Requirements === | ||
- | |||
- | Each PECL package should adhere to the following requirements: | ||
- | |||
- | * Declare PHP_EXTNAME_VERSION in php_extname.h | ||
- | * Use PHP_EXTNAME_VERSION in the zend_module_entry declaration (for phpversion()) | ||
- | * Use PHP_EXTNAME_VERSION in PHP_MINFO() (the phpinfo() source) | ||
- | * The " | ||
- | * Use a recognized versioning structure (so that version_compare() can be useful and users can easily see which version they have). See [[|Version naming]]. | ||
- | |||
- | === Optional Extras === | ||
- | |||
- | The cvs $Revision$ or $Id$ placeholder (or any other revision control placeholders) may be used in PHP_MINFO(), | ||
- | |||
- | === Version Naming === | ||
- | |||
- | There are two kind of packages in PECL: normal PHP extensions providing a set of APIs (e.g. http, enchant, fileinfo) and those providing only data (e.g. timezonedb). Normal extensions should use the standard version number defined below. Data packages should use the versioning offered by the underlying package: | ||
- | |||
- | * Standard version: 2.2.11 | ||
- | * timezonedb version: 2008.2 (for February 2008) | ||
- | |||
- | The vast majority of PECL packages fall into the ' | ||
- | |||
- | * A version string **must** include a major, a minor and a patch level number (x.y.z) Please note that all are version numbers are mandatory. | ||
- | * A package version has a " | ||
- | * The state should always be added as a suffix unless the state is " | ||
- | * //Note that the PEAR installer cannot recognize hyphens in a package version string// | ||
- | * 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, | ||
- | |||
- | //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/ | ||
- | |||
- | * 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 " | ||
- | * The first release with state " | ||
- | * BC may only be broken in releases that have a version number of " | ||
- | * Features may only be added in releases that have a version number of " | ||
- | * For releases that only fix bugs the version number should be " | ||
- | * The state should always be added as a suffix unless the state is " | ||
- | * 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 | | ||
- | |||
- | |||
- | === Core Modules in PECL === | ||
- | Johannes Schlueter - as Release Master of the PHP 5.3 series - made it known early in the proceedings that he has concerns over -dev, alpha or beta tags appearing in PHP core module versions. There' | ||
- | |||
- | The idea of using the tag ' | ||
- | |||
- | **// | ||
- | |||
- | === Please comment on the pecl-dev mailing list === |
rfc/peclversioning.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1