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
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/
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.
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
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
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/
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.
Jan
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.
--
Pierre
@pierrejoye | http://www.libgd.org
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
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
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/