Re: RFC: Versioning for core modules

Steph Fox wrote:

Actually this is tagged onto the end of the PECL versioning RFC - it's not a whole new one: http://wiki.php.net/rfc/peclversioning

I'll post it on-list instead: 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.

Having a base and extended RFC isn't so helpful. The detail in the Extended RFC makes it easier to see the intent and to comment on. One of the "problems" I'd like to see listed is being able to identify the exact code base a customer reported a problem on. Knowing whether it was from PECL on not can be useful information. In the Extended RFC, the use of a minor number is only really explained in the table. I think it's worth adding some guidelines about the kinds of changes that could cause a major or minor version to be bumped. Some guidelines on whether a Beta must/should/could be followed by a RC would be helpful. Overall I'm comfortable with Pierre's RFC. (That's not a final vote!) The unresolved issue for me is about Core modules in PECL. Is there a list of these modules? Without it, my view is based on OCI8. Versioning the PHP 5 code as 1.x and its equivalent PHP 6 code as 2.x is simply confusing. I'm happy to leave the PHP 5.3 and PHP 6 OCI8 extensions with the same version for now. Reasons: the only code difference is for Unicode, the PECL releases won't run on PHP 6, and PHP 6 is not common enough for there to be a problem identifying it. Having a -core suffix would let me tell the provenance of the OCI8 extension used by a customer. Made up example:

    Time/event                              | Extension Version
    ----------------------------------------+------------------
    PHP 5.2 released                        | 1.5.1-core
    PHP 5.3 development, no ext changes     | 1.5.1-core
    PHP 5.3 development, bugs fixed         | 1.5.2-core
    PECL beta released                      | 1.5.2b1
    PHP 5.3 released                        | 1.5.2-core
    PECL release made                       | 1.5.2
    PHP 5.4 development, no ext changes     | 1.5.2-core
    PHP 5.4 development, bugs fixed         | 1.5.3-core
    PHP 5.4 development, new features       | 1.6.0-core
    PECL beta made                          | 1.6.0b1
    PECL RC release made                    | 1.6.0RC1
    PECL release made                       | 1.6.0
    PHP 5.4 development continues           | 1.6.0-core

Another unanswered question is about PHP 5.2 - does the PHP_XXX_VERSION macro change need to be implemented there too? Chris -- Christopher Jones, Oracle Email: christopher.jones@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad Follow me: http://friendfeed.com/ghrd