Re: RFC: Versioning for core modules

Hi Chris,

Having a base and extended RFC isn't so helpful.

The rationale here was that the original RFC didn't go anywhere near so far, and is close to completion. I don't think I have the stamina to take responsibility for an RFC that moves the goalposts every time the goal's within reach :)

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.

Wouldn't the -core/-dev/PECL release distinction achieve this?

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!)

It's not either/or - more a case of 'how far can we take this'. PECL was originally offered as a relatively loose development environment (http://news.php.net/php.pecl.dev/5), so any proposal to tighten the rules is likely to be contentious. This is why Pierre's recommendations apply to *new* packages rather than existing ones. It's also why I didn't want those recommendations to muddy the waters for my initial proposal.

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.

There are 49 on my working list from last week, attached. This includes PECL extensions shipped with PHP 4 as well as PHP 5. It might even include some from earlier, I hopefully erred on the side of caution.

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.

This year. I'd tend to agree for now, but we need to know how to approach this when PHP 6.0 is released without having to go through yet another round of versioning proposals.

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?

This depends entirely on Ilia, as PHP 5.2 Release Master (cc'd). It could be more immediately useful that way - e.g. we could start using it sooner in snaps scripts, and potentially on pecl.php.net - but in the long run it doesn't really make a lot of difference. - Steph

Extension Versioning macro Defined as Defined in zend_module_entry PHP_MINFO ===================================================================================================== bz2 n/a* n/a* n/a* NO_VERSION_YET* n/a* cpdf n/a* n/a* n/a* NO_VERSION_YET* n/a* crack n/a* n/a* n/a* 0.3* n/a* cyrus n/a* n/a* n/a* NO_VERSION_YET* n/a* db n/a* n/a* n/a* NO_VERSION_YET* n/a* dbx n/a* n/a* n/a* NO_VERSION_YET* 1.1.0* dio n/a* n/a* n/a* 0.1* n/a* domxml DOMXML_API_VERSION* 20030407* php_domxml.h MACRO MACRO filepro n/a* n/a* n/a* NO_VERSION_YET* no MINFO* filter n/a* n/a* n/a* 0.11.0* $Revision* fribidi n/a* n/a* n/a* 0.1* n/a* hash PHP_HASH_EXTVER* 1.0* php_hash.h MACRO n/a* hwapi n/a* n/a* n/a* NO_VERSION_YET* n/a* hyperwave n/a* n/a* n/a* NO_VERSION_YET* $Id* informix n/a* n/a* n/a* NO_VERSION_YET* n/a* json PHP_JSON_VERSION 1.2.1* php_json.h MACRO MACRO mcal n/a* n/a* n/a* NO_VERSION_YET* n/a* mcve PHP_MCVE_VERSION 5.2* php_mcve.h MACRO MACRO mnogosearch n/a* n/a* n/a* NO_VERSION_YET* n/a* msession n/a* n/a* n/a* NO_VERSION_YET* n/a* ncurses n/a* n/a* n/a* NO_VERSION_YET* n/a* notes n/a* n/a* n/a* NO_VERSION_YET* n/a* oci8 n/a* n/a* n/a* 1.3.1 1.3.1 Beta openssl n/a* n/a* n/a* NO_VERSION_YET* n/a* oracle n/a* n/a* n/a* NO_VERSION_YET* n/a* ovrimos n/a* n/a* n/a* NO_VERSION_YET* n/a* pdf PDFLIB_PECL_VERSIONSTRING* 2.1.5* pdf.c* MACRO MACRO pdo n/a* n/a* n/a* 1.1dev* n/a* pdo_dblib n/a* n/a* n/a* 0.9* n/a* pdo_firebird n/a* n/a* n/a* 0.3* n/a* pdo_mysql n/a* n/a* n/a* 0.9* n/a* pdo_oci n/a* n/a* n/a* 0.9* n/a* pdo_odbc n/a* n/a* n/a* 0.9* n/a* pdo_pgsql n/a* n/a* n/a* 0.9* z.version* pdo_sqlite PHP_PDO_SQLITE_MODULE_VERSION* 1.0.1* pdo_sqlite.c* MACRO MACRO pfpro n/a* n/a* n/a* NO_VERSION_YET* n/a* simplexml n/a* n/a* n/a* 0.1* $Revision* soap n/a* n/a* n/a* NO_VERSION_YET* n/a* spl n/a* n/a* n/a* 0.2* n/a* sqlite PHP_SQLITE_MODULE_VERSION* 2.0-dev sqlite.c* MACRO MACRO swf n/a* n/a* n/a* NO_VERSION_YET* n/a* tidy PHP_TIDY_MODULE_VERSION* 2.0* tidy.c* MACRO MACRO w32api n/a* 0.3.0-dev n/a* 0.2* n/a* xmlreader n/a* n/a* n/a* 0.1* n/a* xmlwriter n/a* n/a* n/a* 0.1* n/a* xslt n/a* n/a* n/a* NO_VERSION_YET* n/a* yaz PHP_YAZ_VERSION 1.0.14* php_yaz.h MACRO MACRO yp n/a* 1.0.1-dev n/a* NO_VERSION_YET* n/a* zip @PACKAGE_VERSION@* 1.9.1* package.xml* REPLACED* REPLACED*