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

> From: Greg Beaver [mailto:greg@chiaraquartet.net] > Sent: Thursday, September 18, 2003 4:41 PM > 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). Actually thinking about it again I think version numbers should be bumped. There may actually be a number of hidden BC breaks as well that for some reasons haven't been picked up by the extensive unit test every package features ;-) Therefore I really think that for rewrites the major version number should be bumped. If the developer feels that he has everything under control while doing a minor rewrite I don't have a problem with him deciding not to bump the major version number. Regards, Lukas