Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65682
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.212.53 cause and error)
Message-ID: <51117F86.3050001@lerdorf.com>
Date: Tue, 05 Feb 2013 13:54:14 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Karoly Negyesi <karoly@negyesi.net>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <CAOfzkkz3DC+aVb4c73QHGRzZv=1z=nG4uexdJh2n8h3ATGBBOA@mail.gmail.com> <CAEZPtU6UdX4uyR7tLomi==DNbmJduHoxa=qmb+dd2bJQKcoxjw@mail.gmail.com> <CAOfzkkwQNKRrX+MQ3JutkVWmHsCLZetJMp7AubA52E+=MSCcXw@mail.gmail.com> <510EBF98.4060900@lerdorf.com> <CAOfzkkwU4=K86582q1kgh_w2Ecubxij-ExecBLF_aHEWMY=dew@mail.gmail.com> <CAKOpQSyuKoSY8JGNhYUxPNTECR30Kk8j8MY5r4tY0qS_xBju2A@mail.gmail.com> <CAOfzkkwLODYXEyzEb1uNp6+ANUSZ9w80p3L7S5YoT6iGA1zRhA@mail.gmail.com> <5110AFFB.8040303@lerdorf.com> <CAOfzkkyAC98g71ScsVfDdeG4YB7Dy6i8_1kH0eKH1DT9e9uH9g@mail.gmail.com>
In-Reply-To: <CAOfzkkyAC98g71ScsVfDdeG4YB7Dy6i8_1kH0eKH1DT9e9uH9g@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Proposal for serious BC compatibility aka language
 versioning
From: rasmus@lerdorf.com (Rasmus Lerdorf)

On 02/05/2013 12:16 PM, Karoly Negyesi wrote:
>> Yup, so please test it against 5.5 now. Have you done so? It is rather
>> trivial to do. Grab it from git or there is a tarball at http://qa.php.net
> 
>>> Let me describe my world. I am working on an open source package. So
>>> does another 1000 or so developers. And another 10 000 adds modules
>>> (or maybe you'd call them plugins). I do not even know how many then
>>> adds custom, site specific code. This whole pile of software forms an
> 
> Care to explain how am I supposed to test all that against 5.5?
> Obviously you'd need every project owner doing this but they won't
> because their hosts are not even on 5.4 so why would they even think
> of 5.5? (5.4? A lot of people are on 5.2.)
> 
>> Yes, I would say it is unattainable. You are essentially asking that we
>> don't make any changes.
> 
> Where did I say that?
> 
>> Nothing that could possibly affect existing code
>> down to and including any potential warning messages even if that code
>> is obviously incorrect, insecure and/or not doing what the developer
>> intended. That means no new keywords, no new notices, no bug fixes. What
>> exactly can we do in a new version then?
> 
> new keywords is an interesting discussion to have -- it's actually the
> first real thing to discuss as far as I can see. For example that is
> something that version strings would tremendously help. You do not
> need to maintain the whole lot of behaviors for every version just the
> parser? Also, new keywords typically introduce new syntax. Here's an
> example, a quick github code search found
> https://github.com/chriso/klein.php/blob/master/klein.php#L600 this.
> function yield() is not a valid usage of the new yield keyword nor is
> yield() so perhaps it's not impossible to accomodate this kind of
> code? Let's discuss.

Let's not. We are not going to add version tags. There is nothing to
discuss here.

> New error messages could be INI controlled to avoid surprises.

And no, more ini switches to control the nature of notices won't happen
either, sorry.

> Why no bugfixes? Absolutely yes to bugfixes -- once again if a piece
> was not running before then that running in a new version is breaking
> *forward* not backwards compatbility. If a bugfix changes behavior,
> then again, that needs discussion, do you have any good examples? I am
> not familiar enough with the bugs to say "here's a bugfix which made
> foo(NULL) return NULL instead of FALSE" or somesuch.

Very few bug fixes are simple in the sense that they make something work
that didn't work at all before. Usually they fix behaviour, generally in
edge-case scenarios, but not always. Two examples from PHP 5.4:

We discovered that the output of our Tiger hash was wrong. This has been
corrected in 5.4. If you have stored pre-5.4 Tiger hashes you are going
to need to fix these. See the comments of http://php.net/61307 for the
code to generate the old hashes for upgrade purposes.

The output from pack() was non-standard as well. We have brought that in
line with pack() from Perl and other languages. This can potentially
break code as we saw with it breaking Pear's Tar implementation.

Does this mean we shouldn't fix stuff like this? I don't think it does.
The way to handle it from user apps is to test your app against new
versions as early as possible and to make it clear that Drupal version
7.X is fully compatible with PHP version 5.4. It may work with later
versions, of course, but as a project you should test and state which
versions it is guaranteed to work with. Once you have done sufficient
testing with 5.5 you can certify a specific version of Drupal as being
compatible with 5.5. I don't think it needs to be any more complicated
than that.

-Rasmus