• Version: 0.1
• Date: 2008-03-21
• Author: Steph Fox
• Status: Under Discussion

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)
• Utilize $Revision or $Id as well as the version number in PHP_MINFO() (leave this 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 can easily make a patch for the 'low-hanging fruit' so long as there's consensus on this. The rest of PECL may be a slower process.

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 '-dev' if yours is one of the few that does!

Following discussion, we agreed that use of $Id/$Revision should be the choice of the extension developer. Some love it, some don't find it useful at all. (Changed this stricture above).

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's clear and version_compare() works between versions. However, existing extensions that have already used x.x versioning in a package release rather than x.x.x have to be accommodated, due to a quirk of version_compare(). For similar reasons we also need to accommodate 'b1' as well as '-beta', for example. (I draw the line at -stable and -devel, both of which states should be obvious through the version number.) We CANNOT have -dev as a release state because PHP uses -dev to mean 'not a release state'.

The problem of symlinked PECL extensions arose, with Johannes (RM for the PHP 5.3 series) concerned to avoid any extensions tagged as -beta, -alpha or -dev in a full PHP release. The infrastructure for having full PECL releases ship with each new PHP release isn't in place at this time. As an interim measure, the workaround for this is to tag version strings in the core extension with the suffix -core, on the grounds that core extensions can safely be said to have gone through as much QA as PHP itself.

The problem of PECL releases geared to a specific PHP branch also arose, but since PHP_5_2 and PHP_5_3 branches already exist in PECL (largely containing symlinked extensions to the appropriate PHP branches) I see this more as something that needs altering in the snaps scripts. PECL modules in PHP-version branches should IMHO override whatever's in PECL CVS HEAD for that module, for the appropriate version of PHP. (This would presumably also allow symlinked PECL extensions to continue development outside PHP, but don't quote me on that.) At present, PHP version information is only given as part of package.xml in a PECL release, and snapshots are built from the CVS HEAD version of PECL. I propose that the PHP target versions for each PECL release are also given on the project page on pecl.php.net.

We're pretty much through with this. Items left open to future debate are:

• The problem of version-specific PECL builds (not really within the remit of this RFC)
• The problem of core module versioning
• 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.