Re: RFC: PEAR Changes / Scope

> > 1. I propose that PEAR be split into CORE and an EXT (or CONTRIB), where > > CORE is the stuff we've already got, and the stuff that has to go > > through a rigorous approval process. Basically, Java's standard > > library. EXT would be code that conforms to a certain level, but less > > so than CORE. Duplication would be allowed in EXT, but we would still > > be talking about classes, not apps or forums or builders. EXT could be > And the advantage? Please check the "php4/pear/ vs. pear/"-problem. EXT would > break #1 and #3. If you won't follow the standards, then go to Sourceforge, you > can create a package.xml and you can install your package with the > pear-installer from Sourceforge. There is no need to distribute them from > pear.php.net. Agree on this. It doesn't make sense to me to introduce another level of complexity with a split into CORE and EXT. Many (like me :) already had problems to understand why there's php4/pear and pear/ in the CVS. Every new developer would have to read through the ML from the beginning to understand, why things are this and that way. What are standards for, if they get rewritten every couple of months? Moreover, doesn't we already have a split into "CORE" and "EXT" just by the split into php4/pear and pear/ ? From the FAQ: Only the PEAR base classes which are needed by most PEAR elements and the installer system will remain in php4/pear and will be bundled with every new release automatically. s/base/CORE/ and you have what you've been looking for, don't you? - Mike