Newsgroups: php.internals,php.pecl.dev
Path: news.php.net
Xref: news.php.net php.internals:36428 php.pecl.dev:5269
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 64.97.136.174 cause and error)
Message-ID: <003701c88db8$915a4410$c6fc1f3e@foxbox>
Reply-To: "Steph Fox" <steph@zend.com>
To: "Pierre Joye" <pierre.php@gmail.com>
Cc: "internals" <internals@lists.php.net>,
	<pecl-dev@lists.php.net>
References: <00dc01c88c90$c34c5cc0$c6fc1f3e@foxbox> <fe05d1540803240425u57bd967evb4ecd93866a45a20@mail.gmail.com>
Date: Mon, 24 Mar 2008 14:08:41 -0000
Organization: Zend Technologies
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
From: steph@zend.com ("Steph Fox")

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
>