Re: BC break?

Marshall Roch wrote:

Consider this scenario: Package Foo extends PEAR, although it doesn't use the PEAR class at all. This means that Foo::raiseError() should work from a script that is using package Foo. It's obvious that PEAR.php shouldn't be included, and Foo shouldn't extend PEAR needlessly. But would it break BC to remove it? On a similar note, say Foo depends on Bar, and Bar changes it's API and Foo updates accordingly. Methods used directly by the user that are inherited from Bar don't work anymore, apparently breaking Foo's API. How does one deal with this? There's no real reason to release Foo2, but the API *technically* did change...

These are great questions :) For the first, I think you'll find that this qualifies as a text search-and-replace BC break, and I would also say you can actually maintain BC by defining a raiseError() method in Foo that includes PEAR.php, and passes values to PEAR::raiseError() - no BC break, no worries. Most BC breaks can be solved with similarly clever thinking, which is why requiring a major version bump may lead to either much better design or much more kludgy code to avoid BC breaks :). For the second, I'd say that if a package inherits an API, and the underlying API changes, the package should bump its version. I don't think it is necessary to do a Foo2 even if Bar goes Bar2, this isn't a rewrite of the Foo package, and it should be updated to use the latest version of the package. Remember, the whole point here is that once Bar2 comes out, Bar is a dead, deprecated package, and all future releases of dependent packages should depend on Bar2. Of course, if you find that the incredible new features of Bar2 make you want to rewrite Foo as well, then I'd say Foo2 might make some sense. It's about as case-by-case as they come, I think. The important thing is that there exists only two options for BC breakage: 1) bump major version number 2) release Package2 2.0 as the actively developed version of Package. Which one is chosen will be up to the developer. The first case would mean there is no option to have both Foo 1.x and Foo 2.x installed, the second option would mean both can be installed and co-exist, even if Foo2 is the only actively developed version. Ooh, that was much clearer than my RFC, I'm gonna forward this to Lukas, and see if he likes it :) Greg