Re: a case for subpackages

Marshall Roch wrote:

Greg Beaver wrote:

2) Upgrading a subpackage that has changes is much more efficient in both time and bandwidth than upgrading the entire package at once. New subpackages can be released without a new release of the main package

I just installed PEAR on my machine so that I can test my XML_RPC changes more easily. I noticed that the pear command line has a "cvsdiff" option. Wouldn't it be even more efficient to have something like "pear patch <package>" to patch the code with the latest [stable] release from CVS? This, of course, would require that using PEAR's CVS becomes mandatory, which I don't see as such a bad thing.

I'm very against requiring PEAR CVS. phpDocumentor, for example, had a long history of using a different CVS repository before becoming a PEAR project. We have developers who have absolutely nothing to do with PEAR who help to develop it, and there is no good reason to throw everything off by requiring them all to get PHP cvs access and change all of their local repositories, not to mention the complete loss of any commit history. Patches contains absolutely no stability information, and they also lose all the benefits of the pear installer (replacements, install-as, OS-specific install, different baseinstalldir). For these reasons, it would be less efficient for complex packages/applications (the only ones that would use the subpackage feature are complex, so there you go :). Greg