solution2

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2008/04/02 16:00		current
Line 50:		Line 50:
	* A version string must include a major, a minor and a patch level number (x.y.z) Please note that all are version numbers are mandatory.		* A version string must include a major, a minor and a patch level number (x.y.z) Please note that all are version numbers are mandatory.
	* A package version has a "state" (as indicated in the package.xml file), which describes the maturity. The state may be one of "alpha", "beta", "RC" or "stable" (listed in the order of code maturity). Please note that the state "RC" is achieved by using the state "beta" and appending the version number with "RC" followed by an integer		* A package version has a "state" (as indicated in the package.xml file), which describes the maturity. The state may be one of "alpha", "beta", "RC" or "stable" (listed in the order of code maturity). Please note that the state "RC" is achieved by using the state "beta" and appending the version number with "RC" followed by an integer
-	* The state should always be added as a suffix unless the state is "stable" 'a', 'b' or 'RC' (respectively for alpha, beta and release candidate) followed by a numeric value. E.g. '1.2.1b3', '1.0.0RC2', '1.1.0a1'	+	* The state should always be added as a suffix unless the state is "stable". Valid suffixes are 'a', 'b' or 'RC' (respectively for alpha, beta and release candidate) 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//		* //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 "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 "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.

solution1

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2008/04/04 09:55		current
Line 3:		Line 3:
	* Status: Work in progress		* Status: Work in progress

-	=== The Problem ===	+	=== History ===
-	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.	+	PECL versioning has historically been fairly anarchic. From a user perspective, 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 falling back on trial-and-error. From a developer perspective, it was 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 ===	+
-	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 ===		=== 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.	+	As of April 2008, all PECL packages should use the PHP_EXTNAME_VERSION macro appropriately and declare the macro in the file //php_extname.h//, and all but a handful have been altered to do so. The one area that is still open for discussion concerns PECL packages that are also core extensions in one or more versions of PHP.

	=== Requirements ===		=== Requirements ===
Line 54:		Line 33:

	* 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'
	* 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.

Line 60:		Line 39:

	=== Core Modules in PECL ===		=== Core Modules in PECL ===
-	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.	+
		+	Johannes Schlueter - currently Release Master of the PHP 5.3 series - made it known early in the proceedings that he had concerns over -dev, alpha or beta tags appearing in PHP core module versions during a PHP release. 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.		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.

PHP Wiki

solution2

solution1