Newsgroups: php.internals,php.pecl.dev
Path: news.php.net
Xref: news.php.net php.internals:36457 php.pecl.dev:5286
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 64.97.136.139 cause and error)
Message-ID: <024c01c88df2$2aadbb90$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> <01cf01c88dd9$b04e99e0$c6fc1f3e@foxbox> <fe05d1540803241123y66d99f27u2658609897eb5728@mail.gmail.com>
Date: Mon, 24 Mar 2008 21:00:59 -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")

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