Re: [RFC2] Handling Backwards Compatibility in PEAR

On 19 Sep 2003 at 17:08, Greg Beaver wrote: [...] > If a package intends to remove or change the name of API elements, > this must be clearly marked in at least 1 release before they are > removed (see HTML_QuickForm). When the API is changed, the version > number shall increase to the next whole number. In other words, if > the API changes for Foo version 2.7.2, the next release is version 3.0 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. 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 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. Stefan