Re: Whither PEAR2 (Was: Re: [PEAR-DEV] PEAR2 Standards)
| From: | Alan Knowles | Date: | Thu, 27 Dec 2007 23:59:25 +0000 |
| Subject: | Re: Whither PEAR2 (Was: Re: [PEAR-DEV] PEAR2 Standards) | ||
| References: | 1 2 3 4 5 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-48809@lists.php.net to get a copy of this message | ||
Could we be a bit more carefull about how the two interact - removing PEAR2 coding standards from the PEAR1 manual is a good start...
The website needs quite some consideration:
- How to link to pear2 web site?
- How to help users to report bugs on the right package - pear1/pear2...
Probably something like
- top banner? [PEAR2:: for PHP6 only, namespaces and autoloadable packages]?? - not sure how else do diferenciate it...
Which bit's of the PEAR2 standard can/should be backported to PEAR1?
- PEAR_Extension? - mmh... strongly recommended, but not essential for PEAR1 (if PHP4 compat is required?..) - yes we still have v. large clients with PHP4 servers..
- Data files (allow files either as documented in PEAR2 standards or as sub directories of the package...)
- Not sure why you want to create a src directory... - seems just change for change sake... ?
On other things for PEAR1?
- base classes: PEAR / PEAR_Error: - Is anyone else interested in working out how to replace/remove these as requirements for PEAR1??
Regards
Ala
p
Greg Beaver wrote:
Alan Knowles wrote:Actually I'm sure there are lots of people who would love to see PEAR2 as it has been documented, however, the aims of PEAR2, are pretty incompatible with the current aims of PEAR1. In some seems to make more sense as a semi-seperate project. What I guess is really needed is a vision on how PEAR1 will continue while PEAR2 takes the focus of those that have been pushing it so much.This is a very good point - I had assumed it would be obvious, but here goes: Pyrus and PEAR can co-exist quite peacefully. Here are some ways: From the installer side of things: * Pyrus can be used to manage existing PEAR installations with the (yet-to-be-written-but-easy-to-do) PEAR-based registry option. * Pyrus maintains 100% backwards compatibility with existing package.xml 2.0-based packages - this means the ancient things released with only package.xml 1.0 will need to be managed with PEAR. * PEAR2-based packages will be hosted in the pear2.php.net channel (domain is already set up), so users happily using the PEAR installer will not even notice PEAR2 unless they upgrade to a version of PHP that only bundles Pyrus - and there will be some kind of migration help (there will have to be) that has not yet been solidified, probably some kind of compatibility "pear" command, but I haven't thought this through deeply, and of course, outside help on the matter is greatly appreciated when the time comes. From the repository dev side of things: * all existing channels and their packages will continue to be installable via Pyrus or PEAR through the pear.php.net channel. * packages may still be proposed for inclusion in PEAR1 if for some weird reason a dev has a moral objection to putting them in PEAR2, nothing in the new standards prevents this, and nothing is intended to prevent this. The forward momentum and changes of PEAR2 will be enough justification for most package developers to skip over to writing for PEAR2, and if not, we'll tweak PEAR2 until it is the best choice. I and PEAR Group firmly believe in competition based on the value inherent in a project, not on some wish-washy PR dream.Mixing what will become PEAR2 into the PEAR1 infrastructure looks like it will be confusing to users, developers and end users. Is it time to consider creating pear2.php.net ? - and cvs.php.net/pear2 (or svn..) for those projects and working out how to separate the two divergent projects? This will give considerably more flexibility for anyone working on a PEAR2 vision, to enable PEAR1 to thrive (or die...) in a reasonable manner...As you point out, this is a very good idea. Fortunately, svn.pear.php.net was created for this purpose. This repository has several major advantages over cvs.php.net, the most obvious being that PEAR has 100% control over the repo and therefore can implement far more PEAR-friendly options and changes without checking it with an external project that has no reason to bend to accomodate PEAR.(On a slightly cooler head day ;) - Alan...I appreciate this, and I'm glad I waited to reply until this message, it reassures me once again that we really do have the same interests at heart :). Thanks, Greg