Hi Pierre,
OK you lost me completely. You would rather have no version capability
in
PECL beyond the module itself? What's so confusing about 'if you have
PECL
code that is specific to PHP 6 use the PHP_6_0 branch in PECL'?
I still have no idea what you are talking about. For which build? PHP
snapshots or PECL snapshots? releases builds?
I'm totally confused by your confusion :) All of those builds could
prioritise an appropriately-named branch. The only one that currently does
this is the PHP build (any), for core extensions only. There's no total
independence of PHP in PECL because everything's geared towards one or
another of the PHP branches anyway. On the other hand, there are a number of
PECL modules that manage very well to cover all the bases in a single
package that builds against all PHP branches.
Those multi-version modules share a problem with the symlinked ones -
nowhere to experiment - since CVS HEAD is effectively a release area in both
cases.
You obviously haven't looked at the source, because pecl4win doesn't use
any
PECL branches at all.
It does or was supposed to last times Edin discussed it. There was a
set of branches to be used for each PHP version, but I did not check
the code lately.
I did. It uses different PHP branches, not different PECL branches - the
only exception is for core modules, which are built (from a hard-coded list)
as branch-specific PHP extensions rather than as PECL modules. That said,
PECL developers don't tend to use PECL branches anyway - the vast majority
develop purely in CVS HEAD, which isn't a big problem so long as the code
builds against all versions of PHP.
From the very begining you defined what you like to do right now
(after having made some clarifications):
1. Provide DLL per active branche
Actually that would be 'per release branch'. I've no intention of providing
PECL release DLLs for development branches - what would be the point?
2. add version info in these DLLs
You missed:
3. add version info in the PHP_MINFO section using the same macro.
The 2nd point is why you have created the RFC.
and 3rd...
That's what we should
try to finish this dicussion and the RFC. For the 1st point you
clearly said that you want it simple and easy as a first step, I
hardly follow you right now as you move in every direction about every
single need of PECL. And that's exactly what I was trying to avoid,
not to block a good move or innovations, but to avoid a chaotic move
in many direction without any specs. Please don't take this last
sentence badly, it is also valid for me.
I don't do this in isolation, Pierre :)
The problem is that it is very easy in such discussions to be
distracted by other topics and forget the initial RFC (versionning).
If we don't focus on it and your initial goal, we will waste energy
and time to discuss things again and again without any actual results.
I certainly wasted a great deal of time yesterday responding to lengthy
emails rather than getting the job done. I don't intend to do the same
today.
I'm sorry if you taken any of my answers badly or personally, none of
them was meant to hurt you or your ideas. It is a discussion about a
RFC and I try to understand what you are asking or discussing. I also
hardly try to stay on the topic.
It's simple. I want to see PECL modules versioned in a standard way. The
issues raised concerning this (not all of them on-list) have been:
- symlinked modules: We agreed to use the -core tag for these for now.
- PHP-version-specific modules: (most likely case: a PECL module in CVS HEAD
builds against everything but PHP 6). This is dealt with in package.xml, but
we still don't have a way to distinguish a PHP 6-only module either through
phpinfo() or on the pecl.php.net download page. However, unless it's a core
module, that same code will be used in snaps. That was the bit I was trying
to talk about earlier, but the scripts for snaps and bundles (any) would
need to be adapted to prioritise the appropriate branch in PECL for my
suggestion to work.
- versioning rules: You want to use PEAR's versioning structure, and I agree
with all of that apart from the -devel and -stable tags... x.0.0 is by
definition stable, anything less is by definition pre-alpha unless it has
an -alpha tag. However the existing PECL packages don't always use PEAR
rules, so we need to adapt a little to the current circumstances while also
recommending the PEAR x.x.x structure for new packages. Also, as with PHP,
anything other than a release should be tagged -dev, excepting modules that
ship with the core (as per temporary measure above).
- space for experimental development: This isn't a major problem because a)
experimental code shouldn't really be distributed and b) it's already
possible to create a non-release branch or branches in PECL for this kind of
thing. Just look at SDO :)
We need to revisit: core module versioning and PHP-version-specific PECL
builds. I think we've already enough to work with for the majority of cases
tho'.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
