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 10:36] – sfoxrfc:peclversioning [2008/07/16 13:00] – Fix URLs scottmac
Line 1: Line 1:
 ===== Request for Comments: PECL Versioning ===== ===== Request for Comments: PECL Versioning =====
- 
-  * **Version:** 0.9 
-  * **Date:** 2008-03-21 
-  * **Author:** Steph Fox 
-  * **Status:** Nearing completion 
  
 === The Problem === === The Problem ===
-Currently, PECL versioning is fairly anarchic. Looking into the problem of distributing PECL binaries, this is one of the first areas that could and should be addressed. +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-&-fail process. Windows PECL binaries should have reliable version information in the DLL resources (physically visible in the file properties) as well as at runtime (through phpinfo(), phpversion('extname') etc.). Some of the processes in php.net that currently use hard-coded lists could also benefit from a standardized versioning process. This problem has to be fixed to bring PECL to a higher quality and reliability level.
- +
-=== 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 with -dev at all times except during a package release +
-  * **Use** a recognized versioning structure (so that version_compare() can be useful and users can easily see which version they have). That is, x.x.x(-dev|-alpha|-beta|RC) //PEAR doesn't recognize hyphens in a package version string - use x.x.xax|x.x.xbx rather than -alpha|-beta// +
-  * **Utilize** $Revision or $Id as well as the version number in PHP_MINFO() //up 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 be deleted) +
-  * 1 doesn't declare a zend_module_entry +
-  * 1 doesn't have versioning capability (pre-PHP 4.1?) +
-  * 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, but don't use -dev +
-  * 25 already declare and use a versioning macro in php_extname.h, but the name could be anything +
-  * 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 +
- +
-=== Update 22/3/08 === +
-I committed a change to the Windows build script to enable independent versioning for PECL modules in DLL properties. +
- +
-=== Update 24/3/08 === +
-Following discussion, it was agreed that use of $Id/$Revision should be the choice of the extension developer. +
- +
-=== Update 25/3/08 === +
-Open items: +
- +
-  * The problem of PHP version-specific PECL builds +
-  * The problem of core module versioning +
-  * Labelling core modules as such on the pecl.php.net project homepage +
-  * Labelling PECL releases with their target PHP branches on the pecl.php.net project homepage +
- +
-=== Update 2/4/08 === +
-Most of the modules in PECL now comply fully with the following rules: +
- +
-  * use x.x.x numbers for versioning +
-  * tag the version with '-dev' during the development cycle, thereby distinguishing snaps from release builds +
-  * declare the macro PHP_EXTNAME_VERSION in php_extname.h +
-  * use the macro in zend_module_entry (so phpversion('extname') will work) +
-  * use the macro in PHP_MINFO (so phpinfo() will include module versioning information) +
-  * express alpha, beta or RC using the format: 1.0.1a2, 1.0.0RC3, 2.5.3b1 +
- +
-The seven 'private' extensions are slightly behind the rest. The dev teams involved have been alerted and asked to update their versioning structure. +
- +
-Two modules (maxdb and timezonedb) use a versioning structure based on third-party code that can't sensibly be altered. +
- +
-One module (APC) already uses the proposed versioning structure, but declares a non-standard macro in a non-standard header. A handful of other modules (less than a dozen) declare their standard macro in a non-standard file. I'll do what I can to bring all modules fully into line, since a reliable convention potentially allows the declaration to have uses beyond populating Windows DLL properties. We could remove the hard-coded lists from our snaps scripts, for one... +
- +
-One standard module (wxWidgets) doesn't yet declare a PHP_MINFO() function and can't be built for testing in order to add it. The author has been contacted and asked to add this. +
- +
-Obvious CVS errors and any modules containing no code have been deleted from PECL. As a side-effect, so have the final two GPL'd extensions. +
- +
-Hartmut Holzgraefe has updated PECL_Gen to reflect the new versioning requirements. +
- +
-=== Core modules === +
-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's no process in place to export PECL releases into the PHP core; many of the modules in PECL are symlinked into the PHP core, affecting both snapshots and releases. This has benefits for the PECL modules concerned, in that they get far more testing than they otherwise might during the PHP development cycle, but the point remains that they are linked directly rather than filtered through an independent PECL release process.+
  
-The idea of using the tag '-core' rather than '-dev' to reflect the status of those dual-nature extensions came up. The PECL versioning could then remain x.x.x (no tag) during PECL releases, with the version number itself used to reflect alpha/beta development status. Christopher Jones of Oracle voiced his concern regarding core PECL modules in separate development branches, which happens with core symlinking (and can of course occur manually too). "Should the version in CVS HEAD be tagged -core6?" Pierre Joye recommended that module versions with a conflicting API simply reflect this in the version number, e.g. 1.0.3-core for PHP 5.* and 2.0.3-core for PHP 6. The PECL releases would be 1.0.3 and 2.0.3 respectively, and the version bumped to 1.0.4-core/2.0.4-core following release.+There are actually two RFCs (proposals) to deal with version numbering in PECL and for core PHP extensions in general.
  
-**//Feedback on this subject would be appreciated!//**+  * [[rfc:peclversioning/solution1|Base proposal]] by Steph Fox 
 +  * [[rfc:peclversioning/solution2|Extended proposal]]  by Pierre A. Joye
  
-=== Please comment on the pecl-dev mailing list === 
rfc/peclversioning.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1

Page Tools