Re: [RFC] BC breakage in PEAR - how to handle it properly

Hi Lukas, Lukas Smith wrote:

One reason why I say this is that a rewrite should be communicated to the user. There maybe drastic changes in the behaviour even if there are no BC breaks: 1. performance 2. quality 3. compatibility of patches If we find a different way to communicate a rewrite then I don't have a problem with not requiring a major version increase. How about requiring a complete rewrite to downgrade to at least beta stability for 2 releases minimum? In addition, if the version is required to increment by 100 to the next available round 100-number, that might do it

1.1 => 1.100 1.102 => 1.200 In addition, as much as automation is a good thing, users still have to read release notes :). Any of the three points you raise must be clearly documented if there is a rewrite (and there have been no problems with this so far). Perhaps pear revert is needed? Not the patch I suggested, but an automatic solution, where the last-installed version of packages is stored in the registry, and used to install over the top of existing installations (it would only work 1 level back, but that's the idea). Greg