On 02/04/2013 10:35 PM, Karoly Negyesi wrote:
> OK, let's try this again.
>
> Maybe language versioning is out. That's sad, but this thread brought
> to light a much more important problem I would like to try to address.
>
> I have long felt the PHP team is living in another world I do.
>
> 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
> ecosystem which is quite sizeable. The software is somewhat popular.
>
> Users form a pyramid. The bottom is shared hosts. Shared hosts that we
> need to take into consideration. So if the shared world just barely
> switched to 5.3 default then, alas, we can't release a version that
> requires PHP 5.4 because there is no shared support for it. Also, it
> worths mentioning that one of the more popular server OSes, Ubuntu LTS
> also doesn't have a PHP 5.4 yet. Without software demanding 5.4, hosts
> won't upgrade. This is a vicious circle that is superb hard to break.
>
> I was told in this thread that the new release process solves this and
> "it is our and our users role to explain that to their ISPs, admins,
> etc".
>
> Well, what am I to explain? As I mentioned previously, if a shared
> host does a PHP upgrade and their users see new error messages, then
> the host have a support problem. When I tried to point this out, I got
> strawman arguments (about segfaults and bugfixes which breaking
> forward compatibility and absolutely having nothing to do with BC) and
> ridicule ("the problem is with your code"). You can ridicule the
> codebase all you want, but the codebase a) works b) tested. This
> doesn't change the fact that breaking backwards compatibility a little
> is like being a little pregnant. Either you are or you are not and
> currently you are not. This is sad because apparently a lot of work is
> being put into this and then on a minor point it falls short of the
> goal.
>
> It would make everyone's life so much easier if all the Drupal 8 code
> that is being written and tested with 5.4 would just work 5.5 without
> *any* problem.
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
> I would absolutely love not to have this conversation again three
> years from now when we need to decide to ship Drupal 9 with PHP 5.5 or
> 5.4 -- because we could indeed do a campaign when 5.4 is due to change
> to 5.5 outright because it won't break BC with 5.4. Is this absolutely
> unattainable?
Yes, I would say it is unattainable. You are essentially asking that we
don't make any changes. 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?
Just as a point of reference, the array to string conversion notice that
was added in 5.4, which seems to be at the center of your argument, has
found 6 potential bugs across 3 different companies I work closely with.
This was a good and useful change to a large part of our userbase. You
should also recognize that there is also a large faction that wants to
see us make even more drastic changes along these lines and not less. We
have to try to balance both ends of this spectrum.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
