BC breakage results

Hi, We've reached what seems to be a typical position: lots of stuff has been said, and no one is in favor of anything to solve the problems, so business continues as usual :). Unresolved questions that need attention: 1) What should be done about minor BC breakage? - it is a bad idea to have Foo version 2.0 and Foo2 version 2.0, this will only cause confusion - nobody likes any solution proposed. We can't ignore this. 2) How much of an API change would be necessary to do a Package2 release? ======= I am starting to believe that PEAR wants an impossibility: you can't have BOTH BC and automatic upgrades without some kind of structure. The only solution that can solve the problem without the changes I've proposed is to explicitly state that any packages with dependencies must depend on the latest version of the package, or be considered to be outdated and no longer viable. So, which is it folks? Solve the problem by allowing older versions of packages to co-exist with their newer versions, or simply keep things as they are, and change the way the "ge" relation works? In essence, the solution I've proposed would turn PEAR into a repository where multiple kinds of packages that do the same thing with different APIs co-exist. This is exemplified by the question of whether File_Passwd that is currently proposed should be released as File_Passwd2. I didn't realize this until that question was raised. This would not be a good way to handle different APIs ultimately. So, before I trot out another RFC, I'd like to ask if we can look at the two different kinds of BC breaks and another solution that is more radical. What if a more specific kind of dependency was introduced? In other words, if I use a few public methods of a class in a package, it would be best to specify a dependency on these methods. <dep type="pkg" rel="ge" version="1.3"> Foo <subdep type="method" class="Foo" params="$first, $second">handleBar</subdep> </dep> In this way, if the <provides> section listed not just methods, but their API, then an automatic check of API change can be made to determine BC. This solution would involve a lot more detail in package.xml. Of course, none of it would be required, as a generic dependency could still fail if the major version increases (this should occur for the more detailed package.xml as well). This detailed dependency would allow minor BC breakages to be caught, without requiring a major version number increase. Unfortunately, it wouldn't solve this problem for user applications that are not registered in PEAR, documentation would have to solve that one. Greg