Re: BC breakage results

On Friday, September 19, 2003 4:45, Greg Beaver wrote: > 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> Note that a the data type/format of the params or the returned values may change too, that's other kind of BC break out of an automated control. Also this won't be flexible enough for applications, extensions or as you pointed out, external packages. My main feel about this topic is that we need communication and upgrades. Any developer breaking his API should clearly document that fact at least in the release notes, and any developer depending on this package should adapt his package for this change, or at least set his package incompatible with that version. This should be the common and recommended way to treat API changes, is how the overall software world works. Developers should take in mind that a lot of people may be using his package, so he should be BC as much as possible. See the PHP itself, almost all php software is still valid with major upgrades (ok, in some cases minor changes are required). I guess that we need to automate communication of API break, encourage people to don't break the API providing compatible layers and document how to do a good design that will survive in the future. A dynamic dependencies system may help too, where a developer can mark releases incompatible with certain version. To provide Foo and Foo2 support would solve the rest of cases, but shouldn't be the common way to go. Or we could go more far with the adoption of the slot system plus a pear_load() func, which would allow the installation of multiple versions of the same package. -- Tomas V.V.Cox mailto:cox@idecnet.com