Re: [RFC_v3] Handling Backwards Compatibility in PEAR [hopefully the final draft]
| From: | Jan Schneider | 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