Re: BC breakage results

Hi Alexey Borzov wrote:

Hi! Greg Beaver wrote:

1) What should be done about minor BC breakage?

Minor BC breakage should be clearly communicated and resolved between package developers and clearly stated in release notes for the users. For the record: I don't think that we should require x.0 releases for each minor BC breakage. Or else some PEAR packages risk reaching 20.0 quite soon.

2) How much of an API change would be necessary to do a Package2 release?

That should be decided by package maintainer. My point of view is that if this is feasible to have 2 versions of package and use them *both* at the same time, then go for Foo2. I'd also say "API change that cannot be handled by Search/Replace".

Documentation and automated testing will solve most of the problems. Of course, it is more fun to write RFCs than docs and tests. ;P

Maybe for you ;) - I would much rather write code, docs and tests, but if I just coded the solution I see as the best one for BC handling and committed it with unit tests and docs, I guarantee that people would not be happy - they would most likely scream for my head on a stake :). If you don't think so, check the archives for the touchiness of committing a new feature to the core (Tomas's DTD package, for instance). How's this for a solution: Add a requirement to the coding standards page that says if any other PEAR packages depend on your package, and you are going to make a minor change, you must notify the maintainer of that package so that they can do a release that is compatible with your new package's version, or one that requires an earlier version. A two week waiting period should be allowed for people to respond, and then if nothing is heard back, it's their problem and not yours if the minor break kills their package. As for the installer, I will code a new pear revert command that accepts 1 argument: a package name, and has the -a --alldeps command. The revert command will simply restore a package to a previous install, including any dependencies that must be downgraded (if a package has a lt relation that is no longer satisfied) With this command you can do: [version 1.2 is installed] $ pear upgrade Foo installing version 1.4 [testing shows package YYY is broken now] $ pear revert Foo reverting to version 1.2 or, [Foo 1.2 is installed, Bar version 1.5 is installed, Foo 1.2 requires Bar < 2.0] $ pear upgrade -a Foo installing Foo version 1.4 installing Bar version 2.0 $ pear revert Foo dependencies fail $ pear revert -a Foo reverting to Foo 1.2 reverting to Bar 1.5 or, $ pear revert Foo Bar reverting to Foo 1.2 reverting to Bar 1.5 The command would only revert packages that had been upgraded, and only work once per upgrade. This wouldn't work: $ pear install Foo Foo installed successfully $ pear revert Foo cannot revert - never upgraded since install or last revert $ pear upgrade Foo upgrading to 1.5 $ pear revert Foo reverting to 1.0 $ pear revert Foo cannot revert - never upgraded since install or last revert This will allow multi-user installations to quickly and safely undo a package upgrade that breaks everything, particularly in the pear upgrade-all case. Greg