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

>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 What about following the Linux kernel versioning where od numbers are development releases and even are stable releases foo2.5.23 is the 23 development release of foo2 version 5 that will become foo2.6 when released foo2.6.11 is the 11th patch level to the foo2.6 stable code (bugfixes, security problems, ...). Then it is fairly easy for developers that depend on packages to tell where the development is, and for users to tell what is stable and what is development.... > > 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 > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >