• Version: 0.9
• Date: 2008-03-21
• Author: Steph Fox
• Status: Nearing completion

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.

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

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

I committed a change to the Windows build script to enable independent versioning for PECL modules in DLL properties.

Following discussion, it was agreed that use of $Id/$Revision should be the choice of the extension developer.

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

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.

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!