Re: [RFC2] Handling Backwards Compatibility in PEAR

Hi! Stefan Neufeind wrote:

This is not what we discussed, right? This way you can't have a 2.x and 3.0 co-exist on a system. For sure this should be no problem on a computer you're working on - but it might become a problem in webhosting-environments.

Lets say this loudly: if you want to fully control your environment, you'll need to keep a private copy of PEAR. If you are using a hosting that does not allow this, tough luck. You get what you pay for, generally.

You can't just judge on what version installed packages depend but you also need to judge: - if any packages that may need to be installed in the near future depend on the old version - if any apps (that you don't know of because they're not listed in the package deps) still need the old version

I think it is not feasible. If a new version of, say, glibc comes out Linux ditributors do not do clever hacks to make old and new glibc versions co-exist. They simply rebuild the existing packages for the new glibc. Why shouldn't we do the same?

Even if you remove one or two functions or rename them you will break BC - and this should, in my eyes, be a new Foo2, v2.0. For sure the dev should consider this version step / API breakage carefully so he doesn't run into version 68.5 after a year :-)) So if the API changes we could suggest that the new API set is thought about carefully and that all plans for the foreseeable future are considered in one (!) API-breakage-step.

Package maintainers tend to change. Careful planning will not help here.