Re: BC breakage results

Jan Schneider wrote:

If there is any chance of Foo going to 2.0, Foo2 is not Foo2, it is a

separate package that does the same thing as Foo. Perhaps this is in fact the litmus test of whether a package should go to Packagex where x is a major version number.

I still think that this would lead to confusion. You can bump your minor versions up to 1.100 or more for package Foo. 2.x should be reserved (and mandatory) for package Foo2.

Clearly what I wrote leads to confusion - what you say is exactly what I'm proposing :) - package Foo will be allowed to go to 2.x for major rewrite if and ONLY if Foo2 doesn't exist and will never exist. If at a certain point, a major API change is needed, then Foo development stops except for bugfixes, and Foo3 is released as 3.0. Foo 2.x is always allowed in this case, but Foo 3.x is never allowed if Foo3 exists. If Foo needs a major rewrite after Foo3 has been released, then, well, let's just say that Foo should be renamed Fool :). Seriously though, the point of release Foo3 will not be to have a continually developing Foo package alongside Foo3, but to allow slower developers to catch up to Foo3 without forcing them to do so faster than they are able to do it. For instance, say two years down the road, PHPUnit for PHP 6 comes out which is not compatible with PHPUnit 1.x simply because it uses PHP 6 features that cause parser errors in PHP 5. In those 2 years, there are TONS of unit tests written for PHPUnit 1.x. Upgrading to PHPUnit 2.0 would be insane, because every single unit test would need to be rewritten. Instead, PHPUnit2 2.0 is released, which allows people who have unit tests written for PHPUnit 1.x to not have to touch them, since they work just fine. New unit tests could take advantage of PHPUnit2, and in fact, people could run both the 1.x unit tests and 2.x unit tests in the same program using PHPUnit and PHPUnit2 require_once 'PHPUnit.php'; require_once 'PHPUnit2.php'; This is a hypothetical example of the need to allow simultaneous installations. I also think that only packages that create persistent structures based on the API will have this problem. Many packages could simply force users to modify code if they want to upgrade, the way it works now. If we add BC checks in the installer and pear revert, then we've covered our bases. Greg