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/03/25 16:15] – sfox | rfc:peclversioning [2008/04/02 16:30] – sfox | ||
---|---|---|---|
Line 1: | Line 1: | ||
===== Request for Comments: PECL Versioning ===== | ===== Request for Comments: PECL Versioning ===== | ||
- | |||
- | * **Version: | ||
- | * **Date:** 2008-03-21 | ||
- | * **Author:** Steph Fox | ||
- | * **Status:** Under Discussion | ||
=== The Problem === | === The Problem === | ||
- | Currently, PECL versioning is fairly anarchic. | + | Currently, PECL versioning is fairly anarchic. |
- | + | ||
- | === A Solution? === | + | |
- | I would like to formally propose that all PECL modules: | + | |
- | + | ||
- | * **Declare** PHP_EXTNAME_VERSION in php_extname.h | + | |
- | * **Use** PHP_EXTNAME_VERSION in both the zend_module_entry declaration and PHP_MINFO() (the phpinfo() source) | + | |
- | * **Tag** the version | + | |
- | * **Use** | + | |
- | * **Utilize** $Revision or $Id as well as the version number in PHP_MINFO() (leave this to the individual developer) | + | |
- | + | ||
- | === Some Facts and Figures === | + | |
- | There are currently 214 modules in PECL. Of these: | + | |
- | + | ||
- | * 1 is written in PHP | + | |
- | * 3 are SAPIs | + | |
- | * 2 are no longer hosted in PECL (and should | + | |
- | * 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 | + | |
- | * 25 already declare and use a versioning macro in php_extname.h, | + | |
- | * 27 already declare and use a versioning macro somewhere | + | |
- | * 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 | + | |
- | + | ||
- | === Final Comment === | + | |
- | I can easily make a patch for the ' | + | |
- | + | ||
- | === Please comment on the pecl-dev mailing list === | + | |
- | + | ||
- | + | ||
- | === Update 22/3/08 === | + | |
- | I have just committed a change to the Windows build script to enable independent versioning for PECL modules there, so long as those modules stick with defining PHP_EXTNAME_VERSION x.x.x[-dev|-alpha|-beta][RCx] in php_extname.h. Since the vast majority of PECL modules don't define that macro yet, this won't affect too many people - but please, do start using ' | + | |
- | + | ||
- | === Update 24/3/08 === | + | |
- | Following discussion, we agreed that use of $Id/ | + | |
- | + | ||
- | We need to create versioning standards for new PECL developers. Pierre has recommended that we stay with PEAR's versioning standards. I don't mind so long as the package versioning' | + | |
- | + | ||
- | The problem | + | |
- | + | ||
- | The problem of PECL releases geared | + | |
- | === Update 25/3/08 === | + | There is actually two RFCs (proposals) to deal with version number in PECL and for the PHP extension in general (core). |
- | We're pretty much through | + | |
- | * The problem of version-specific PECL builds (not really within the remit of this RFC) | + | * [[peclversioning/ |
- | * The problem of core module versioning | + | * [[peclversioning/ |
- | * Labelling core modules as such on the pecl.php.net project homepage, since any package releases available there will be older than the version in the host PHP branch or branches | + | |
- | * Labelling PECL releases with their target PHP branches on the pecl.php.net project homepage | + | |
- | Several developers have given me permission to update their module versioning info to fit the proposed structure. This will affect roughly 25% of all PECL modules. |
rfc/peclversioning.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1