Hi, On Mon, Mar 24, 2008 at 10:00 PM, Steph Fox <[EMAIL PROTECTED]> wrote: > 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.
Now I'm a bit confused. What are yout talking about now? PHP snapshots or PECL snapshots? releases builds? I can answer to the rest of your post once I know better what you are referring to. I fear that you are making too strong relations between pecl's cvs and PHP's cvs. As I can understand that one may like to have the same branches, I don't want to have to use them. PHP branches do not fit well to pecl development, as you noticed already almost all packages can be built against all php versions. The goal is to have a stable branch and maybe some expiremental branches (they are not really relevant in your case, build a dll for each active PHP branch). 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
