# Status of PHP 5.4 - Thread: https://externals.io/message/76524 - Original archive: https://news-web.php.net/php.internals/76524 - Started by Jan Ehrhardt on 2014-08-14T21:34:42+00:00 - Messages: 10 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #76524 — Jan Ehrhardt — 2014-08-14T21:34:42+00:00 URL: https://externals.io/message/76524#76524 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? Jan --- ## #76525 — Andrea Faulds — 2014-08-14T21:41:09+00:00 URL: https://externals.io/message/76524#76525 · In reply to: #76524 > 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? I’m curious about this too. The release process RFC says only bug fixes after 2 years, and it is well beyond that now (5.4 came out March 2012). Look at the wikipedia page: https://en.wikipedia.org/wiki/PHP#Release_history That 5.4 bit should be yellow. 5.6 ought to be green, too, but alas this release, like every, has been delayed. -- Andrea Faulds http://ajf.me/ --- ## #76526 — Chris Wright — 2014-08-14T21:55:09+00:00 URL: https://externals.io/message/76524#76526 · In reply to: #76525 > > > > > […] > > I’m curious about this too. The release process RFC says only bug fixes after 2 years, and it is well beyond that now (5.4 came out March 2012). > > Look at the wikipedia page: https://en.wikipedia.org/wiki/PHP#Release_history > > That 5.4 bit should be yellow. 5.6 ought to be green, too, but alas this release, like every, has been delayed. For me this is a better way to explain why 5.4 is not (currently) security only. We maintain the current and the previous, we should not arbitrarily change the status of the previous before there is a new current. The release of 5.6 should push 5.4 into security-only state, rather than the 5.3 EOL. I realise in this case it should happen at almost the same time (I think the plan is that 5.6.0RC3 is the last RC?) but let's imagine that 5.7 is delayed by 5 years for some reason - it's reasonable to expect that 5.4 would be dropped a long time before 5.7 is released in this scenario, since "security only" mode is (as I see it) only to give stragglers the chance to upgrade, we don't want to maintain 3 branches for the sake of it. The release process helps to ensure that upgrading should now be considerably less painful that it previously was, and saying goodbye to 5.3 means that all currently maintained branches have been (largely) subject to this process. This makes "security only" for the sake of stragglers less relevant, meaning that we shouldn't need to keep 5.4 alive for nearly as long as 5.3 has been. Because of this, when 5.4 *is* EOL, that doesn't necessarily mean that 5.5 is suddenly security only. IMO, YMMV Thanks, Chris --- ## #76528 — Jan Ehrhardt — 2014-08-14T22:32:38+00:00 URL: https://externals.io/message/76524#76528 · In reply to: #76526 Chris Wright in php.internals (Thu, 14 Aug 2014 22:55:09 +0100): >The release of 5.6 should push 5.4 into security-only state, rather >than the 5.3 EOL. I realise in this case it should happen at almost >the same time (I think the plan is that 5.6.0RC3 is the last RC?) ... There will be a 5.6.0RC4, so it will take at least three weeks. Jan --- ## #76533 — Stas Malyshev — 2014-08-15T01:18:12+00:00 URL: https://externals.io/message/76524#76533 · In reply to: #76524 Hi! > 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. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ --- ## #76538 — Jan Ehrhardt — 2014-08-15T08:10:38+00:00 URL: https://externals.io/message/76524#76538 · In reply to: #76533 Stas Malyshev in php.internals (Thu, 14 Aug 2014 18:18:12 -0700): > > […] > >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. Jan --- ## #76540 — Pierre Joye — 2014-08-15T08:53:45+00:00 URL: https://externals.io/message/76524#76540 · In reply to: #76538 > Stas Malyshev in php.internals (Thu, 14 Aug 2014 18:18:12 -0700): > > […] > > 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. -- Pierre @pierrejoye | http://www.libgd.org --- ## #76543 — Ferenc Kovacs — 2014-08-15T09:28:27+00:00 URL: https://externals.io/message/76524#76543 · In reply to: #76524 > 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? > > Jan > > -- > > > > Hi, the EOL process for 5.3 is a bit different than for the other versions: https://wiki.php.net/rfc/php53eol the release process rfc (https://wiki.php.net/rfc/releaseprocess) governs the releases since 5.4: 2+1 year of support after the initial X.Y.0 release. as pointed out, 5.4 is already past the 2 years of bugfix support, so we should announce it that it is on security fixes only. I guess it wasn't announced because we are trying to keep the EOL times with the new releases, and in an ideal world where we can always perfectly match the 12 month release cycles those would be matching, but based on the last two minors, we can't really keep up with the 12month release cycle, so I think that we should either stick with the release process rfc and announce the extended support and EOL dates based on the original release date, or update the releaseprocess RFC to state that we move into extended support/EOL when the the new version in that year is released. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #76548 — Ferenc Kovacs — 2014-08-15T10:31:10+00:00 URL: https://externals.io/message/76524#76548 · In reply to: #76540 > > > […] > > 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 --- ## #76564 — Stas Malyshev — 2014-08-15T18:25:11+00:00 URL: https://externals.io/message/76524#76564 · In reply to: #76543 Hi! > the release process rfc (https://wiki.php.net/rfc/releaseprocess) governs > the releases since 5.4: 2+1 year of support after the initial X.Y.0 release. > as pointed out, 5.4 is already past the 2 years of bugfix support, so we > should announce it that it is on security fixes only. 5.4.32 is already in RC and will be released next week. 5.4.33-dev is already containing some non-security fixes. So we could just arbitrarily announce that starting noon today we stop accepting non-security bugfixes into 5.4, or we could choose a less arbitrary cutoff - such as release of 5.6 or 5.4.33. I would prefer the less arbitrary route, I don't see much harm in having the bugfixes last a little longer, but having more natural version succession - i.e. saying we always have 2 stable branches and one in security fixes. > process rfc and announce the extended support and EOL dates based on the > original release date, or update the releaseprocess RFC to state that we > move into extended support/EOL when the the new version in that year is > released. I think it would be more natural and accommodating for the realities of the release process. The thing is we will have delays, we will have bad RCs, we will have people going on vacations or being too busy, and having a scheme that can accept this while still preserving the general structure seems better to me than literal day-counting. If this means 5.4 has extra 1/2 year of bugfixes - I don't see big harm done by that. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/