Re: [RFC2] Handling Backwards Compatibility in PEAR

From: Date: Sat, 20 Sep 2003 09:59:25 +0000
Subject: Re: [RFC2] Handling Backwards Compatibility in PEAR
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-21836@lists.php.net to get a copy of this message
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. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft

« previous php.pear.dev (#21836) next »