| Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision |
| rfc:peclversioning:solution1 [2008/04/02 16:01] – pajoye | rfc:peclversioning:solution1 [2008/04/04 09:55] – sfox |
|---|
| |
| === The Problem === | === The Problem === |
| 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. | Currently, PECL versioning is fairly anarchic. From a user perspective, it's 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 falling back on trial-and-error. From a developer perspective, it's impossible to know exactly which code base a given bug was reported against. Windows PECL binaries should have reliable version information in the DLL resources (physically visible in the file properties), and PECL packages across all platforms should have this information available at runtime through phpinfo(), phpversion('extname') etc. Some of the processes in php.net that currently use hard-coded extension lists could also benefit from standardized versioning within the source files. |
| | |
| | Resolving these issues will help bring PECL to a higher level of quality and reliability. |
| |
| === Some Facts and Figures === | === Some Facts and Figures === |
| * 3 do the whole thing in reverse and use the release version from package.xml | * 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 | * 136 either hard-code the version, use $Id alone, use $Revision alone or ignore the whole thing |
| | |
| | === Update === |
| | As of 31st March 2008, the figures given above are incorrect: 145 PECL packages now use the PHP_EXTNAME_VERSION macro appropriately, and a mere handful now declare it in a file other than php_extname.h. The current focus is on PECL packages that are also core extensions in one or more versions of PHP. |
| |
| === Requirements === | === Requirements === |
| * A version string **must** include a major, a minor and a patch level number (x.x.x) | * A version string **must** include a major, a minor and a patch level number (x.x.x) |
| * The status of the package may be described using 'a', 'b' or 'RC' followed by a numeric value, e.g. '1.2.1b3', '1.0.0RC2', '1.1.0a1' | * The status of the package may be described using 'a', 'b' or 'RC' followed by a numeric value, e.g. '1.2.1b3', '1.0.0RC2', '1.1.0a1' |
| * //Note that the PEAR installer cannot recognize hyphens in a package version string// | |
| * In package.xml, the 'status' field for a release may be any of "dev", "alpha", "beta" or "stable". These states should be reflected in the version number: a "stable" release should be at least 1.0.0, for example. A Release Candidate is signified by RCx in the version number and a "beta" status in package.xml. | * In package.xml, the 'status' field for a release may be any of "dev", "alpha", "beta" or "stable". These states should be reflected in the version number: a "stable" release should be at least 1.0.0, for example. A Release Candidate is signified by RCx in the version number and a "beta" status in package.xml. |
| |
| If you need further guidance, please refer to the extensive PEAR version naming rules at [[http://pear.php.net/group/docs/20040226-vn.php]]. The one major difference is that PEAR packages don't need to use '-dev' during the development cycle; there are no snapshot releases of PEAR. 'dev' is therefore used as a release tag in PEAR, but not in PECL, where it would be likely to lead to user confusion. | If you feel that there should be further guidance, please support Pierre Joye's [[/solution2|extended proposal]] which extends the remit of this one with in-depth guidelines for version numbering in new PECL extensions. |
| |
| === Core Modules in PECL === | === Core Modules in PECL === |