Differences

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

--- rfc:peclversioning [2008/04/02 10:34] – sfox
+++ rfc:peclversioning [2008/08/18 12:49] – Update - the base proposal was implemented across PECL several months ago, but the core extensions still need addressing. sfox
@@ Line 1: / Line 1: @@
 ===== Request for Comments: PECL Versioning =====
-  * **Version:** 0.9
+=== History ===
-  * **Date:** 2008-03-21
+PECL versioning has historically been fairly anarchic. This made it impossible to determine the status of an extension, or whether an update would break binary compatibility with previous versions (or work with a given PHP release) without a long try-&-fail process. Some of the processes in php.net that currently use hard-coded lists could also benefit from a standardized versioning process.
-  * **Author:** Steph Fox
-  * **Status:** Nearing completion
-=== The Problem ===
+The base proposal was implemented across PECL by April 2008. Only the question of what to do about PHP extensions that are both in PECL and in the PHP core - and usually symlinked - remains open. //It would be nice to resolve this before the PHP 5.3.0 release!//
-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.
-=== A Solution? ===
+There are actually two RFCs (proposals) to deal with version numbering in PECL and for core PHP extensions in general.
-I would like to formally propose that all PECL modules:
-  * **Declare** PHP_EXTNAME_VERSION in php_extname.h
+  * [[rfc:peclversioning/solution1|Base proposal]] by Steph Fox
-  * **Use** PHP_EXTNAME_VERSION in both the zend_module_entry declaration and PHP_MINFO() (the phpinfo() source)
+  * [[rfc:peclversioning/solution2|Extended proposal]]  by Pierre A. Joye
-  * **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.
-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.
-**//Feedback on this subject would be appreciated!//**
-=== Please comment on the pecl-dev mailing list ===

Differences

Page Tools