On Fri, Aug 15, 2014 at 10:53 AM, Pierre Joye <pierre....@gmail.com> wrote:
> On Fri, Aug 15, 2014 at 10:10 AM, Jan Ehrhardt <php...@ehrhardt.nl> wrote: > > Stas Malyshev in php.internals (Thu, 14 Aug 2014 18:18:12 -0700): > >>> PHP 5.3 has reached the real end of life. Will the effect be that from > >>> now on PHP 5.4 will only get security fixes? > >> > >>There's no dependency between the two in the release RFC, but it would > >>probably make sense to move 5.4 into "security only" phase once 5.6 is > >>GA, and set EOL date for 1 year since that moment, as we did with 5.3. > > > > OK, given the fact that 'the stable 5.6.0 release should show up on the > > 28th of August', this means that PHP 5.4.32 will be the last normal > > release. > > > > PHP 5.4.33 up until PHP 5.4.44 will be 'security fixes only' releases. > > That being said I would like to understand the underlying reasons why > 5.6 will get out two months late. I see nothing that should have > justified it. I am not blaming anyone but it would be nice to see > where we failed and try to improve that for the next releases. > > the alpha1 was delayed because of the HTTP_RAW_POST_DATA BC break, which took some time for us to come up with an acceptable resolution for all parties. alpha2 was delayed by a week because the windows snaps building wasn't working (checking that is a mandatory step in the RM's checklist: http://git.php.net/?p=php-src.git;a=blob;f=README.RELEASE_PROCESS;h=7a82a5c61453bb436319d54ef88f7bc6090fa0a2;hb=refs/heads/PHP-5.6#l59 ) alpha3 was delayed by a week, because I tagged two days later, and we had some test failures on windows which all turned out problems with the tests so we didn't had to re-tag, we ended up not announcing it on friday(and the windows snap building was broken again). beta1 was delayed by two weeks, mostly because the outstanding session issues (there were some stuff which was accepted in an RFC, but not commited, stuff which got committed but not being part of the rfc, and we even had to revert stuff which was mentioned in the accepted RFC but later good point where brought up to be reverted). beta2 was delayed by a week, I can't find any particular reason, so it was probably just me not having the time to test and tag in time. beta3 was on time beta4 was delayed by a week, I think it was because I was working on improving our travis builds that time (and looking into cross compiling 32bit builds there because travis doesn't have 32bit VMs, but I got hit by some ubuntu packages not properly supporting MultiArch installations) RC1 was on time RC2 was on time RC3 was delayed by two weeks because we had to resolve the issue that 5.6 removes the ability for userland to instantiate any object via the O: trick, and I wanted to provide them an upgrade path so I proposed https://github.com/php/php-src/pull/733 for that. RC4 was on time (maybe we could have skipped it, if the countable::count changes are reverted a day sooner, or if I would tagged a day later). If not considering giving up on quality, then I think there are only two things we can really improve to elimiate the delays: * there were a couple of cases where I felt that I had to put too much effort into convincing some people that introducing a BC break for a no feature is a no-go. to resolve this we can either hope that people will learn that this is our best interest and will be more cooperating, or we can be a bit more strict and start using the RMs veto "karma" and revert stuff if an issue brought up is not resolved in a timely manner. * having only one dedicated RM (plus him having not comfortable enough with the codebase) is less than optimal, Julien couldn't really put into 5.6 as much time as he wanted to, because he already RMing an active release, and traveling to confs, etc. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
