Re: [RFC_v3] Handling Backwards Compatibility in PEAR [hopefully the final draft]

From: Date: Wed, 24 Sep 2003 21:58:14 +0000
Subject: Re: [RFC_v3] Handling Backwards Compatibility in PEAR [hopefully the final draft]
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-21948@lists.php.net to get a copy of this message
Zitat von Stefan Neufeind <stefan@neufeind.net>: > On 24 Sep 2003 at 23:06, Tobias Schlitt wrote: > > > Am Wednesday, September 24, 2003 8:44 PM [GMT+0100=CET], > > artikulierte Matthias Nothhaft <php@mahono.de>: > > > > Hi Matthias! > > > > > Well, I remembered another BC issue: > > > What about PHP5/6/7/8... -> language/syntax changes ? > > > Take the PHPUnit package for example! > > > > Maybe that should be handled in a kind of new file branch. The > > installer should be able to handle the correct package for the PHP > > version. After all another open issue would be how long a maintainer > > should keep to PHP branches allive. > > > > What about that? > > Isn't this "automatically" solved? A new major of PHP comes out only > after a very long time / preparation. If there are fixed needed e.g. > for PHP5 that also work with PHP4 (stricter code-checking or more > warnings or so) then there is no problem fixing them in the current > release cycle. And if you need fixes that demand PHP5 you could add a > dep on PHP >= 5.0 already, right? For a new major version, which is > then directed at PHP5 upward I mean. There still is the subtle case where you have to rename a public identifier because it became a reserved word. In this case a new major release should be made even if it's sort of a bugfix. But it's an API change after all. 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 (#21948) next »