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

On 24 Sep 2003 at 23:58, Jan Schneider wrote: > 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. Yeah, that's what I meant by "automatically solved" in my email. Just follow "the spirit of the RFC" :-)) Renaming a (public) identifier is an API-change and therefor needs a new major. Nothing to discuss ... we all know what to do :-)) But fine that you also seem to agree on the thoughts of the RFC. (Greg - nice work!!!) Stefan