Newsgroups: php.internals,php.pecl.dev
Path: news.php.net
Xref: news.php.net php.internals:36438 php.pecl.dev:5278
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 64.97.136.155 cause and error)
Message-ID: <017901c88dd1$39eb43a0$c6fc1f3e@foxbox>
Reply-To: "Steph Fox" <steph@zend.com>
To: "Pierre Joye" <pierre.php@gmail.com>
Cc: <pecl-dev@lists.php.net>,
	"internals" <internals@lists.php.net>
References: <00dc01c88c90$c34c5cc0$c6fc1f3e@foxbox> <fe05d1540803240425u57bd967evb4ecd93866a45a20@mail.gmail.com> <003701c88db8$915a4410$c6fc1f3e@foxbox> <fe05d1540803240914u1e36be73hd1730d83c719ce3b@mail.gmail.com>
Date: Mon, 24 Mar 2008 17:05:11 -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")

Hi Pierre...

>>  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.
>
> I agree with Greg, only the basic info (what we have now) belongs there.

Apparently there are technical reasons for that. This would've come out in 
that later discussion, but now we have it as a 'given' before we start... 
makes things a little easier for the summer I guess :)

>>  > 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.
>
> It has nothing to do with version_compare, absolutely nothing. What
> I'm saying is only what PEAR already does successfully since years. It
> works very well, it is clear and does not allow some random confusing
> versions like 0.1.0-stable.

Neither does version_compare(). The only problem I've found with it is that 
it doesn't recognize 1.0.0 and 1.0 as the same value, but that's only a 
problem if you change existing patterns. (Bear in mind that there are 
existing patterns for everything that ever had a PECL release, which should 
be honoured if the 'pecl' command is to keep working.) Also, I've found 
nothing in PECL that deems itself 'stable' at 0.1.0, so I think that's a bit 
of a red herring. People seem to have been very good about that on the 
whole.

>>  > 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.
>
> Everything being in php-src is core. No matter what we'll do next
> month or in 10 years.
>
>> 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.
>
> That makes little sense to me. If we provide snapshots from PECL, they
> should follow the same rules than all other PECL extensions.

OK, here's a plan. How about we allow 'core' as a version tag (for use in 
MINFO and RC stuff only - package.xml obviously won't use it, and PECL 
package releases shouldn't either). So you'd have a version string like 
'1.5.0-core' in phpinfo() and in the .dll for core extensions, and in both 
cases the PHP version information is also available. A $Revision or $Id 
string in MINFO would also be useful in core extensions, purely from the 
bug-tracking PoV.

This way you can easily see 1) the package release version, 2) whether or 
not it ships with PHP (and which version), and 3) when the code was last 
updated. We also avoid Johannes' problem of needing PECL release packages in 
a PHP release at a time when this isn't an option.

> If an extension is also available in PHP releases, then the PHP
> snapshots will provide it as well for the bundled versions.
>
>> 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.
>
> Well, if a package has not been touched, it won't be built and the old
> dll will be kept no?

No. We have new PHP versions every now and again...

>> 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.
>
> PEAR already has a nice system for that, I think we can use it as it
> is now. It has been proven to work very well since years.

Feel free to adapt it to PECL :)

>>  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.
>
> It is a non issue as the versions available in the dllinfo is not that
> useful. But to apply a patch to a set of random branches is not really
> a good idea even if it works for many extensions.

I'm not 'applying a patch to a set of random branches'.... tsk!

>>  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.
>
> Yes, that's a real problem in PECL. One cause was to move dead
> extensions from php-src to pecl/ instead of a orphaned repository. It
> also affects only CVS users as long as these packages do not have any
> pecl.php.net entry (without releases for example). What would be the
> best way to deal with dead or orphaned extensions? A separate
> extensions for dead extensions and add a file "REAME.ORPHANED" for the
> orphaned extension?

I think just ORPHANED, like we already have CREDITS and EXPERIMENTAL. 
(Elizabeth will disagree - has already - but I really don't see a better way 
of approaching this.)

> That brings me to the next problem (we can discuss it in a separate
> RFC :), but for the record:
> - dead extension: useless extension like php4 dom or axis (not in pecl 
> anymore)
> - orphaned extension: could still be useful but no active maintainer
> (for example event)

The problem there is that it's not always possible to know the difference. 
How do we know if an extension is 'dead', what are the criteria for that? 
And should they be removed? (My instinct says 'yes' but thousands may 
disagree with me.) Also, who gets to make that decision?

- 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
>