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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
