Re: Proposal for serious BC compatibility aka language versioning

Well, either I misunderstood the policy or it's broken. Here are some (note: please do not argue whether these are more correct than before, they very well might be but they broke backwards compatibility): For example, in 5.4 array_diff_assoc began to throw a notice when casting to string. Again in 5.4, using a string offset against a string throws a warning. It wasn't doing that before. If you want I can dig around in our issue queue for more backwards compatibility breaks but there are some. Regards, Karoly Negyesi On Sun, Feb 3, 2013 at 4:19 AM, Pierre Joye <pierre.php@gmail.com> wrote: > hi, > > On Sun, Feb 3, 2013 at 12:36 PM, Karoly Negyesi <karoly@negyesi.net> wrote: >> Hi, >> >> So, if we are talking about PHP 6, then the opening <?php tag should be >> accompanied by the version it was written for, it was tested with and then >> the engine could switch to a compatibility mode for that version. >> >> Seems to me that this would solve the problem where a host can't upgrade to >> a more modern version for fear of breaking old code. Consequently, open >> source packages -- like Drupal I am deeply involved with -- can't use more >> modern PHP versions decreasing the "push" for hosts to upgrade. This is a >> devilish circle and it'd be great to break it. > > We have been there, no chance to go back again with such tags. > > Also the new release process RFC > (https://wiki.php.net/rfc/releaseprocess) solves the BC issues between > minor updates (5.4 to 5.5, or 5.3 to 5.4 f.e.). It is our and our > users role to explain that to their ISPs, admins, etc. > > Cheers, > -- > Pierre > > @pierrejoye