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