Re: solution for BC breakage

Jan Schneider wrote:

Zitat von Greg Beaver <greg@chiaraquartet.net>:

Tomas V.V.Cox wrote:

<dep type="pkg" rel="ge" version="1">MDB</dep> <dep type="pkg" rel="lt" version="2">MDB</dep>

After I wrote, I was thinking on the subway that this is a much better solution. The reason is that it is also possible to do: <dep type="pkg" rel="ge" version="1">MDB</dep> <dep type="pkg" rel="lt" version="3">MDB</dep> if BC is not broken for the stuff that is needed.

While this is the nicest solution so far, it requires some telepathic view into the future. At the time you depend on a package's API, you don't know when it will break BC.

Well, I don't think any extraordinary acts of telepathy will be necessary :). At the time a release occurs, you simply specify the minimum (nobody is allowed to release a BC-breaking minor version, right? PEAR Group must enforce this). Let's look at package Bar's package.xml for version 1.0 <dep type="pkg" rel="ge" version="1.2">Foo</dep> <dep type="pkg" rel="lt" version="2.0">Foo</dep> Let's say later on, Foo 2.0 is released, and it is BC for your package, then you do a new minor version release 1.1 <dep type="pkg" rel="ge" version="1.2">Foo</dep> <dep type="pkg" rel="lt" version="3.0">Foo</dep> Voila, no more problems. The only problem is with developers who don't maintain their packages and won't do new releases. That's unrelated to the BC problem though :). Your users simply need to pear upgrade Bar to use the new Foo. Regards, Greg