Re,
"will be maintained only there" means that no more PECL releases will
be done. In this case, a notice should be added to tell the users to
do not update or use the pecl package anymore (if they use a younger
php version than the one where the extension was bundled).
I hear what you're saying, I'm just reluctant to go with it because I'm
hopeful this won't be happening for much longer.
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?
It is not about how the CVS works or if it is used at all but if there
will have PECL releases or not once the extension is bundled. For the
record, what we have (or plan to) now is:
- symlink, common case, what we historically did and do
A lot of people don't like symlinking and want to move away from it, so
while it's the common case *now* - again, it probably won't be for much
longer.
- duplicated, how zip works, php-src/ext/zip is a module and is
unrelated to pecl/zip, one has to commit to both tree
Ouf, that's a bit of a burden...
- merge at release time, how phar may work as far as I remember
(that's actually my favourite one as it allows one to work only in
pecl and does not care too much about php releases in his development)
Yes - I believe this was Wez' original intention too.
> 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?
Yes, and how do you define which branch maps to which version? (See my
very first reply for a solution, we can do that later :)
I looked it up:
<quote>
The only problem is for the snapshots, which
version-dev should we use? My plan was to let the developers define
which branch matches which version (like MYEXT_1_8 for 1.8-dev for
example). It should be also possible to let the developers define
which branch should be used for which php versions for the snapshots.
</quote>
I know where you're coming from, but IMHO it would make much more sense to
use the existing PHP_*_* branches where the package code is *specific* to a
PHP version. There's no good way for the snaps machine to know about 200+
different variations on MYEXT_1_8, and likewise there would also be no good
way for a cvs client to grab all the packages for a given PHP branch out of
CVS if everyone used differently-named branches to mean that. At present
it's mostly the symlinked extensions that use those branches, but
pecl/intl's been using PHP_5_2 throughout with no apparent ill effect.
pecl4win and snaps currently don't appear to use PECL branches at all, but
that's probably because most PECL devs don't (yet)... there's no reason I
can see that both couldn't be made to have a handful of named CVS branches
override PECL HEAD for the appropriate PHP branch.
Given that development work generally should be done in CVS HEAD, and that
most packages are coded to run under all current versions of PHP, the only
way it makes sense to form any other kind of branch is if:
1. your package is developed solely in CVS HEAD
2. it builds against all target branches of PHP
3. you want to do some private experimenting
In such a case the experimental code shouldn't really be made available as a
snapshot anyway - snapshots are intended for users, not for developers.
The real problem we have is that there's no obvious way to tell if a PECL
package *release* is geared to a specific branch - and that's only really a
problem because we effectively have two development branches in PHP at
present, HEAD and 5_3. Even so, most PECL devs aim to have their code work
with both 5_2 and 5_3 (and some go much, much further, as you know.)
It can be solved later for the snapshots, for the release it is rather
easy to do :)
In package.xml, yes - but that information doesn't appear along with the
package release info on the site. Having it there would be useful.
The later makes more sense to me. I can imagine a 2.x version for HEAD
and still having 1.x for 5.x
But then we should have a PHP_6_0 branch to host the version-specific 2.x
package development... not a couple of hundred differently-named branches
for the same purpose :) Snaps should build PHP HEAD (only) against your 2.x
and the rest against your 1.x (presumably in PECL HEAD), and both
pecl.php.net and package.xml should have the target PHP version clearly
marked. If/when PHP 6 supercedes PHP 5 you can put your old HEAD code into
the 5_* branch, do a final release from there and ignore it ever after. And
once you're working in a branch - you might as well keep it that way and use
HEAD for experiments, since nothing's going to be released from there and
your target PHP versions are already covered.
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?
Can you post a list in the wiki or to the list so we can validate it
first?
Sure thing. (Could take me a while tho'.)
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
