re, On Mon, Mar 24, 2008 at 7:05 PM, Steph Fox <[EMAIL PROTECTED]> wrote:
> > Yes, it is what we call the common sense. However it would be even > > better to document this common sense so packager (linux distros), new > > developers and users will know it. > > Yes, that's the plan. But, one thing at a time... The "versionning" RFC is the perfect place to describe ... versions :) > > As a summay, we have the following cases: > > > > 1. a PECL package is now in core and will be maintained only there. > > The PECL homepage has to say it > > This doesn't make a lot of sense to me - if they're symlinked, changes made > in php-src ext/whatever are really going into PECL CVS. "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). > 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 - duplicated, how zip works, php-src/ext/zip is a module and is unrelated to pecl/zip, one has to commit to both tree - 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) > > 2. a PECL package is now in core and will still be maintained in PECL. > > For each PHP releases, a PECL release could be done as well so the > > versions can be matched > > This would be the ideal scenario all round, but enforcing it may be > problematic! That's scenarii, not something I like to enforce, only an enumaration of existing cases :) > > 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 :) > >> > 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... > > > > I obviously meant to do not build it again for a given PHP version. > > It doesn't seem to care about mtime anyway, so I was wrong too: > http://cvs.php.net/viewvc.cgi/pecl/fribidi/ > http://pecl4win.php.net/ext.php/php_fribidi.dll It can be solved later for the snapshots, for the release it is rather easy to do :) > > For example HEAD can be a random branch as well. It was not badly > > meant but only a possible source of errors/confusions. > > No... it won't be, because in all cases where there is symlinking, all > affected branches of the same extension will have the same version number - > based on the most recent PECL release and tagged with -core. I'm only > looking at 5_2, 5_3 and HEAD here, no more than that. I'm not sure to understand what you mean. Do you mean that all affected branches will have the same version like all branches (5.x or HEAD) will have the same version? Or do you mean that each branch can have a version? The later makes more sense to me. I can imagine a 2.x version for HEAD and still having 1.x for 5.x > >> 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.) > > > > ORPHANED may do it as well. > > 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? > What a horrible name :) How about pecl_graveyard? Whatever we like as long as it is well documented :) 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
