Newsgroups: php.internals,php.pecl.dev
Path: news.php.net
Xref: news.php.net php.internals:36446 php.pecl.dev:5282
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 64.97.136.161 cause and error)
Message-ID: <01cf01c88dd9$b04e99e0$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> <017901c88dd1$39eb43a0$c6fc1f3e@foxbox> <fe05d1540803241025h5ef7180we0b771af17b4004b@mail.gmail.com>
Date: Mon, 24 Mar 2008 18:05:45 -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,

> Yes, it is what we call the common sense. However it would be even
> better to document this common sense so packager (linux distros), new
> developers and users will know it.

Yes, that's the plan. But, one thing at a time...

>>  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.
>
> It may do it. $Revision will still be there (as almost every extension
> provides it) but it is not very useful (see previous mails).

I know, but it gives a *bit* of a clue in what would otherwise be a void.

> As a summay, we have the following cases:
>
> 1. a PECL package is now in core and will be maintained only there.
> The PECL homepage has to say it

This doesn't make a lot of sense to me - if they're symlinked, changes made 
in php-src ext/whatever are really going into PECL CVS. There's no reason 
there couldn't be a PECL release of a symlinked core package, either (in 
fact pecl/hash should probably have one following Solar Designer's patch). 
Or do you mean non-symlinked packages? If so, are there any PECL packages 
currently in core that are in this situation?

> 2. a PECL package is now in core and will still be maintained in PECL.
> For each PHP releases, a PECL release could be done as well so the
> versions can be matched

This would be the ideal scenario all round, but enforcing it may be 
problematic!

> 3. a PECL package is now in core and will still be maintained in PECL.
> Core and PECL has two completely different roadmaps, I have no idea
> how to actually solve this case :)

Isn't that what CVS branches are for?

>>  We also avoid Johannes' problem of needing PECL release packages in
>>  a PHP release at a time when this isn't an option.
>
> About merging a PECL release in a PHP release at packaging time
> (packaging PHP release), if it is possible to detect whether we are
> building an extension inside php-src or using phpize (via pecl or
> manually) then it would be possible to add the "-core" postfix via a
> simple #ifdef (I'll love to do it for zip).

Cool :)  For the RC stuff I just checked whether the path to the extension 
src included 'pecl' or not.

>>  > 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...
>
> I obviously meant to do not build it again for a given PHP version.

It doesn't seem to care about mtime anyway, so I was wrong too:
http://cvs.php.net/viewvc.cgi/pecl/fribidi/
http://pecl4win.php.net/ext.php/php_fribidi.dll

>>  >> 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 :)
>
> That's what I partially did earlier (x.y.z+1 , x.y+1.z, x+1.y.z). I'll
> add the relevant part to the RFC and merge the points we already
> agreed on.

Thanks!

>>  > 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!
>
> For example HEAD can be a random branch as well. It was not badly
> meant but only a possible source of errors/confusions.

No... it won't be, because in all cases where there is symlinking, all 
affected branches of the same extension will have the same version number - 
based on the most recent PECL release and tagged with -core. I'm only 
looking at 5_2, 5_3 and HEAD here, no more than that.

>>  > 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.)
>
> ORPHANED may do it as well.

Should I start adding these now, where it's very obvious? And should there 
be some note inside the ORPHANED file to say what the extension needs? To go 
back to fribidi again (because it's a simple extension that hasn't been 
touched in 4 years and I know Tal's not likely to come back to it), there's 
a single compiler warning due to snprintf() changes in PHP and no tests at 
all. Nothing wrong with the extension itself, it works fine - but it _is_ 
orphaned.

>>  > 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?
>
> There is many obvious cases:
> - a given extension is hosted somewhere else
> - the service used or targeted by the extension does not exist anymore
> - the extension is superseded by core features (php4 dom for example)
>
> It has to be discussed on a case by case basis anyway but for the vast
> majority, it is rather obvious.
>
>>  And should they be removed? (My instinct says 'yes' but thousands may
>>  disagree with me.) Also, who gets to make that decision?
>
> Having the code still readable somewhere is a good thing. We can
> simply move them in  pecldeadext repository.

What a horrible name :) How about pecl_graveyard?

- 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
>