----- 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

Reply via email to