Re: PEAR 1.3b3 problems

Jesus M. Castagnetto wrote:

Ack. We have to envision that not only single packages will supersede older versions, it might happen that two packages could gravitate to each other and end up merged into a new one that replaces the two older ones, etc.

This is true, but I don't think there is a real need to handle this case automatically in the installer - if the description is updated for one of them and notes to use the other package name, and the other package name is deprecated with the automatic method, things continue as desired. A merge of two packages (we're both thinking of Pager, probably) will never be a completely automatable thing, so I'm against adding that kind of complexity unless you can come up with a really convincing reason. Maintaining one thread should be enough, the way that Pager_Sliding is now deprecated, and Pager continues as Pager. The main benefit of the new BC RFC is that a package like phpDocumentor can now reliably depend on other PEAR packages and expect their basic API to remain constant through the lifetime of the package name (once that package hits stable). If there is a complex merge into another package, I can simply update the dependency in a future version with no serious fear of things blowing up, especially with the new revert command. Me likee. :) Greg