Re: Re: About that PECL versioning thing

Hello Pierre,

Aside from Pierre's arguments in favour of using package.xml to set the extension version (which 3 PECL extensions - two of them Pierre's - do at present), does anyone have any objection to the proposal at http://wiki.php.net/rfc/peclversioning?

I'm not in favour of using package.xml to set the version. I'm in favour of allowing package.xml usage.

Nobody's attempting to prevent package.xml usage, least of all me! I actually want to extend package.xml to give more information (QA related) so that people have more of a clue about what they're dealing with. E.g. code coverage %, maintenance status, whether the package is of general/special interest (this last mostly for hosting companies) and some kind of grading system. But this is all open to discussion and probably won't happen for a long while.

Now, why cross posting, adding a random set of the pecl-dev discussions as comments in the wiki?

Because you told me to do that :) I stopped when it became clear nobody was going to put comments on there.

And the rules about what means a version increment is missing.

We already have three sets of rules for that (PEAR rules, php-src rules, version_compare() rules). Basically if version_compare() can deal with it, it's in - I don't see how any other approach can be justified, since it may mean messing up someone's long-adopted system.

As far as I remember, php-src did not want to have per extension versions.

php-src needs to decide what's core (and takes the PHP version) and what's not. This isn't going to happen overnight, so I've compromised by not using the -dev tag for symlinked extensions and by applying the RC data to PECL builds only. There are a few other packages that won't get a -dev tag because they haven't been touched since the last (often first) package release, ie they're not under active development. These aren't necessarily stable, but that's a whole separate issue... we need a way to clearly mark orphaned packages, both for pear/pyrus and for pecl.php.net.

However, It is fine to add an information about its version to help the users to know if the pecl releases is newer than the bundled version. Can we please keep the discussions in on list? It is already hard enough to follow everything.

There haven't been any off-list discussions about this... unless you count my asking permission from various individuals to add versioning to their packages?

I discovered tonight that I have full PECL karma, so the secondary question is: does anyone have any objection to my making all (or most... I'd leave the package.xml ones for now) PECL modules fit this versioning model?

Many extensions use branches, I would go with a patch posted to pecl-dev and let the respective maintainers apply it to the active branches. (zip has two branches + php-src).

This affects 27 symlinked extensions in 5_2 and 21 in 5_3, all of which I have checked out locally. It's a relative non-issue, for the reasons given above. I started work yesterday on extensions where the maintainer has given explicit permission or where I know for sure they're no longer involved in PHP development (Sterling, Tal). Amazingly, fribidi still works after five years of zero interference :) I'll post patches for the rest on a per-maintainer basis over the coming weeks, but I have to say there are a number of PECL packages I believe are long-time orphans. - Steph

Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php