Re: future of PEAR (was [PEAR-DEV] [Call For

On Tue, 2003-11-11 at 05:49, Greg Beaver wrote: > > Issues concerning subpackaging should IMHO discussed, too. > I wrote an rfc regarding subpackages that received quite literally no > discussion whatsoever :). It is now sitting in the php-src/pear/docs > directory of CVS if you would like to review it. I have every intention > of coding subpackages for PEAR 1.4, as I've written several incarnations > for earlier PEAR versions, and the only extensive code will actually > need to be at pear.php.net rather than in the installer. I really like the approach. Another well thought idea, IMHO. But I'm shure, that this would be cleaner with a PEAR2 approach, because we can integrate subpackes cleaner in CVS by doing sth like: <snip> pear/ Categorie/ Package/ Package.php Subpackage/ Subpackage.php </snip> This directory structure looks much cleaner in my oppinion and could be matched to users PEAR directories, as well as to CVS structure (which would definitly raise developement comfort very much). If we manage changes like this in actual PEAR, I agree, that we do not have to create a new PEAR 2, but as Björn said in some post on this list, we have to make developement easier. > Of course, discussion is good, but I'd hate to see the absolute mayhem > caused by the BC dispute. > Update: after tons of discussion on the list, several revisions to the > RFC, the PEAR group has successfully discussed the BC RFC a few times, > and come to no decisions. This is all second-hand, of course, as I'm > not in the PEAR Group. People are busy, so even critical priorities > slip under the table. The next time I propose an RFC, I think I'll > include some code that does what the RFC says and see if it makes any > difference :) I think that's the only solution, first code, then propose. ;) Nevertheless, the PEAR group should definitly clean up the problem, in any way. What I wanted to talk about next is, by the way, another awkward topic. We defenitly have to talk about PHP5. The second beta is out and we mainly do not want to start again in beta phases, when the new version comes. IMHO it's pretty important that the PEAR installer should be shipped in a well tested version with the first stable release. Maybe I missed something, but are there any concrete solutions for the following issues, which I consider to be neccessary for PEAR on PHP5 in a technical or social way? They are as follows: - Error handling - The old PEAR error system will be outdated, because of the introcuction of exceptions. - A general handling of exceptions should be defined, concerning numbering, naming and other stuff. - Codingstandards - Current standards have to be updated concerning news of PHP5. - New standards have to be defined concerning eg. interfaces, exceptions, etc. - Documentation has to be updated. - No matter how, but IMHO the user should get a definite sign for each package, if it is compatible to the different major version. I think, this should be indicated on the website and in "/pear list.*/" output. And many other smaller or major issues, which did not visit my brain in the last 20 minutes! ;) Regards, Toby