----- Ursprüngliche Message -----
> Von: Lester Caine <les...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
