----- Ursprüngliche Message -----
> Von: Lester Caine <lester@lsces.co.uk>
> An: "internals@lists.php.net" <internals@lists.php.net>
> CC:
> Gesendet: 9:14 Dienstag, 5.Februar 2013
> Betreff: Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
>
> Rasmus Lerdorf wrote:
>>> 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 athttp://qa.php.net
>
> Perhaps when I've finished the time machine ...
>
> In reality we have to make choices where we DO spend time. There is still a mile
> of code out there being used live which is running perfectly on the PHP5.2
> infrastructure. That needs testing and reworking on PHP5.3 and then PHP5.4
> before we get around to 5.5.
Why do you change the infrastructure if the code does not need it? I mean, provide the
infrastructure the code needs and done. There is more than one vendor that offers support for PHP
5.2 infrastructure in the market. What's the deal?
>
> This is perhaps the main problem with accelerating the release timetable in that
> there simply is not enough time to bring everybody along? So something has to
> give and at the moment for me it's going to have to be 5.5 ... but by the
> time all the legacy stuff is up to 5.4 you will be way off in the distance :(
There was no acceleration in the release timetable from my point of view. The whole show was stopped
between PHP 5.2 and 5.3. This has been fixed now by explicitly having the one-year rhythm for major
releases again - documented publicly for the first time in PHP history (IRC). I like the idea to
know that a new major is scheduled for the first of march. The equinox, can't you feel it?
Would be great to know we get PHP 5.6 shipped until the next solar eclipse.
Also these yearly release period (the Rhythm) does not mean that it accelerated. It just helps you
(and everybody else) with dancing, coordinating and planning. E.g. you can choose your speed by
explicitly for example by leaving one major version out (skipping it) because you know when you can
expect the next major release - thanks to rhythm - as well as you know how long it will be supported
by the project.
When we got rhythm I can call my jamaican guy while being a slave to it. Grace Jones knew that.
It's all leisure, no stress. The PHP userbase just grew too large you can find a solution for
everyone. Having a clear release rhythm still helps everyone and looks like an appropriate tool to
me.
And yeah, code, you need to refactor, always. We can't change that, nobody can. PHP might have
made us lazy, which is fine, however, time goes by. Just some weeks ago I killed one of my PHP 5
babies (and it could have run even longer technically, despite the PHP releases since it saw light
of day). The whole application is not needed any longer (thanks to the great improvements we have
with frameworks and libraries since PHP 5.3 and 5.4). Don't work against the community, try to
find good solutions of which everybody can benefit. Sure we all have issues, but the key point is to
be flexible with the solutions. Be it just taking the releases of PHP 5.2 supported by third-party
vendors or keeping up with the later stable leaving a time-window of three years to switch between
one PHP version to the other. Additionally if even this time-frame does not work out for more than
*one* version change, you can even skip up to two major versions to keep up with the
rest of the gang to latest. I think it was never that easy as it is today.
-- hakre