Re: BC breakage results

Hi! Greg Beaver wrote:

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?

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".

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 question is: won't this structure add more problems than it is trying to solve? I haven't seen much complaints about BC breakage from PEAR users, only from few PEAR developers...

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?

I'd go for the third option: don't touch anything. If you don't want to check whether your package will be compatible with latest version of dependency, add explicit version/version range to <dep> tag. This will also communicate something important to the package's users, which will not be so obvious in "automatic" resolution.

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.

Won't work as PHP is not strongly typed. The parameters meaning may change, but the API will *look* the same.

Unfortunately, it wouldn't solve this problem for user applications that are not registered in PEAR, documentation would have to solve that one.

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