Re: [RFC2] Handling Backwards Compatibility in PEAR

On 20 Sep 2003 at 11:59, Jan Schneider wrote: > Zitat von Stefan Neufeind <stefan@neufeind.net>: > > > 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. > > Agreed, this is how I understood the discussion so far. The benefit of > this solution and the original motivation behind Greg's RFC1 was in my > eyes, that we could handle bc breaks without changing the current > installer code. That is because it simply is a new package that can be > installed next to the old one. > > And I still find it confusing for users to have Foo 2.0 as well es > Foo2 1.0 (or should it be Foo2 2.0 then?) as viable version numbers, > even if they can't exist at the same time. As I conclude from the previous discussion if Foo and Foo2 exist, then Foo2 should start with 2.0 and Foo should be <2.0. But if only Foo and Foo3 exist could then Foo be <3.0? Someone said that we could even have Foo 1.999 and therefor wouldn't need to make it 2.0 (Foo2- 2.0) if the API is not broken and a new major release is necessary. Stefan