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