Re: Proposal for serious BC compatibility aka language versioning

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