# 5.3 final release - Thread: https://externals.io/message/74890 - Original archive: https://news-web.php.net/php.internals/74890 - Started by Stas Malyshev on 2014-06-13T23:38:28+00:00 - Messages: 26 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/74890.md?page=2 - 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 --- ## #74890 — Stas Malyshev — 2014-06-13T23:38:28+00:00 URL: https://externals.io/message/74890#74890 Hi! As decided in https://wiki.php.net/rfc/php53eol, 5.3 EOL is 1 year after the 5.5.0 release, which is on June 20th. Do we want to make one last release before EOL with latest security patches (probably in sync with 5.4/5.5 releases planned for June 29)? If so, I can scan the logs and backport the recent security-relevant patches. Last 5.3 was half a year ago so we probably have some, even with remote exploit potential. Thanks, -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #74897 — Ferenc Kovacs — 2014-06-14T07:32:33+00:00 URL: https://externals.io/message/74890#74897 · In reply to: #74890 On Sat, Jun 14, 2014 at 1:38 AM, Stas Malyshev wrote: > Hi! > > As decided in https://wiki.php.net/rfc/php53eol, 5.3 EOL is 1 year after > the 5.5.0 release, which is on June 20th. Do we want to make one last > release before EOL with latest security patches (probably in sync with > 5.4/5.5 releases planned for June 29)? If so, I can scan the logs and > backport the recent security-relevant patches. Last 5.3 was half a year > ago so we probably have some, even with remote exploit potential. > > Thanks, > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > > > > +1 for having a final release, stating in the announcement than there will be no more releases and urging everybody not using 5.3 from a distro who still provides support to upgrade it ASAP. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #74899 — Julien Pauli — 2014-06-14T12:07:14+00:00 URL: https://externals.io/message/74890#74899 · In reply to: #74897 > On Sat, Jun 14, 2014 at 1:38 AM, Stas Malyshev > wrote: > > > […] Very nice idea Stas. One last release before definitive death. Requiescat in pace Julien P --- ## #74903 — johannes@schlueters.de — 2014-06-14T12:45:07+00:00 URL: https://externals.io/message/74890#74903 · In reply to: #74890 Hi, > As decided in https://wiki.php.net/rfc/php53eol, 5.3 EOL is 1 year after > the 5.5.0 release, which is on June 20th. Do we want to make one last > release before EOL with latest security patches (probably in sync with > 5.4/5.5 releases planned for June 29)? If so, I can scan the logs and > backport the recent security-relevant patches. Last 5.3 was half a year > ago so we probably have some, even with remote exploit potential. The last time this was discussed on security@ I intended for "having one release in July to send 5.3 to eternal sleep" I still plan to do that. I won't directly sync with 5.4/5.5, though (unless there is a critical issue requiring this) to have different news. I expect this final EOL to receive more media echo which shouldn't hide other releases. If there are specific changes you want to see in there please send a note to me (cc security@), I'll check myself, too. johannes --- ## #75341 — Ferenc Kovacs — 2014-07-08T15:48:45+00:00 URL: https://externals.io/message/74890#75341 · In reply to: #74903 On Sat, Jun 14, 2014 at 2:45 PM, Johannes Schlüter wrote: > Hi, > > > > […] > > The last time this was discussed on security@ I intended for "having one > release in July to send 5.3 to eternal sleep" I still plan to do that. > > I won't directly sync with 5.4/5.5, though (unless there is a critical > issue requiring this) to have different news. I expect this final EOL to > receive more media echo which shouldn't hide other releases. > > If there are specific changes you want to see in there please send a > note to me (cc security@), I'll check myself, too. > > johannes > > > > -- > > > > Hi Johannes, I would like to cherry-pick http://git.php.net/?p=php-src.git;a=commit;h=4d804aa52d8c74ddcbdb07694b75b38c5eba8004 into PHP-5.3 so that REPORT_EXIT_STATUS=1 make test can be used on every php version provided by travis. currently one has to either manually execute run-tests.php or grepping the make test output for failures. Would that be ok with you? -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #75684 — Ferenc Kovacs — 2014-07-18T07:43:03+00:00 URL: https://externals.io/message/74890#75684 · In reply to: #75341 bump. > > > > On Sat, Jun 14, 2014 at 2:45 PM, Johannes Schlüter > […] > > > […] > Hi Johannes, > > I would like to cherry-pick > http://git.php.net/?p=php-src.git;a=commit;h=4d804aa52d8c74ddcbdb07694b75b38c5eba8004 > into PHP-5.3 so that > REPORT_EXIT_STATUS=1 make test > can be used on every php version provided by travis. > currently one has to either manually execute run-tests.php or grepping the > make test output for failures. > Would that be ok with you? > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu > -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #75699 — Stas Malyshev — 2014-07-19T23:46:15+00:00 URL: https://externals.io/message/74890#75699 · In reply to: #74890 Hi! According to PHP 5.3 EOL RFC, we've now a month past official EOL date, but we've planned to make one final release incorporating most important fixes from upper branches since the last 5.3 release. To help with that, I've created a pull here: https://github.com/php/php-src/pull/730 That lists such fixes. Please review and see if you see anything that should be there and is not, or anything that should not be there but still is. Thanks, -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ --- ## #75878 — Stas Malyshev — 2014-07-22T18:53:31+00:00 URL: https://externals.io/message/74890#75878 · In reply to: #75699 Hi! > According to PHP 5.3 EOL RFC, we've now a month past official EOL date, > but we've planned to make one final release incorporating most important > fixes from upper branches since the last 5.3 release. To help with that, > I've created a pull here: > > https://github.com/php/php-src/pull/730 Did not get any response for that - I guess everybody's too busy discussing the number of the next PHP version :) But I think we still need to release the final 5.3. So I plan to proceed this way: - Release the RC next week - Release the final 5.3 version on August 14th. Any objections to this plan? If anybody has any way to reach Johannes and see if he wants to do it himself later or is ok with the plan above, that'd be great. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ --- ## #75879 — johannes@php.net — 2014-07-22T18:59:07+00:00 URL: https://externals.io/message/74890#75879 · In reply to: #75878 Hi, > Hi! > > > […] Thanks for the work! The list looks good. Any opinions on #67541? WHich was requested there? going strict by the rules it won't qualify. johannes --- ## #75881 — Ferenc Kovacs — 2014-07-22T19:05:24+00:00 URL: https://externals.io/message/74890#75881 · In reply to: #75879 > Hi, > > > > […] > important > > […] > that, > > […] > > Thanks for the work! The list looks good. Any opinions on #67541? WHich > was requested there? going strict by the rules it won't qualify. > > johannes > > not sure, have you seen https://bugs.php.net/bug.php?id=67606 ? --- ## #75882 — Stas Malyshev — 2014-07-22T19:06:07+00:00 URL: https://externals.io/message/74890#75882 · In reply to: #75879 Hi! > Thanks for the work! The list looks good. Any opinions on #67541? WHich > was requested there? going strict by the rules it won't qualify. In principle, I don't have anything against it but I'm not familiar with the code there enough to understand the full set of consequences. I'd like to hear from FPM maintainers/original authors, if they're OK with it then we can have it in 5.3. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ --- ## #75883 — Stas Malyshev — 2014-07-22T19:10:44+00:00 URL: https://externals.io/message/74890#75883 · In reply to: #75881 Hi! > not sure, have you seen https://bugs.php.net/bug.php?id=67606 ? This is worrying. Looks like the patch is not as safe as we've hoped, and causes BC issues for mod_fastcgi, so maybe we should not get it into 5.3. Once it stabilizes, we can backport it into 5.4, but for 5.3 better safe than sorry. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ --- ## #75884 — johannes@php.net — 2014-07-22T19:12:03+00:00 URL: https://externals.io/message/74890#75884 · In reply to: #75881 > > Thanks for the work! The list looks good. Any opinions on > #67541? WHich > was requested there? going strict by the rules it won't > qualify. > > johannes > > > > not sure, have you seen https://bugs.php.net/bug.php?id=67606 ? > > that makes it a "no" :-) johannes --- ## #75885 — David Zuelke — 2014-07-22T19:41:23+00:00 URL: https://externals.io/message/74890#75885 · In reply to: #75883 > Hi! > > > […] > > This is worrying. Looks like the patch is not as safe as we've hoped, > and causes BC issues for mod_fastcgi, so maybe we should not get it into > 5.3. Once it stabilizes, we can backport it into 5.4, but for 5.3 better > safe than sorry. I’ll be working on a fix this week. If you can wait a few days, that’d be grand; if not, then no biggie. David --- ## #75887 — johannes@php.net — 2014-07-22T19:51:00+00:00 URL: https://externals.io/message/74890#75887 · In reply to: #75885 > > > > […] > > I’ll be working on a fix this week. If you can wait a few days, that’d be grand; if not, then no biggie. as we are on the truly last release for 5.3 we have to be safe. We can provide the patch for people who want to experiment, though. So I'd say no for 5.3. johannes --- ## #75984 — George Wang — 2014-07-23T22:22:17+00:00 URL: https://externals.io/message/74890#75984 · In reply to: #75878 Hi, I have a request to include our latest sapi/litespeed V6.6 to the EOL PHP 5.3 release. I thought it was EOL already. We had some difficult to commit our LiteSpeed SAPI code into PHP source repository before, so it is lagging behind our office release. The sapi/litespeed code in 5.3.28 is the V5.5 release, which is very old. We have a script to patch LiteSpeed SAPI to latest version when user build PHP binary for production use. However, we start to push for rpm packages, some vendors only take the official PHP release. It could be a big problem for PHP 5.3 if only the official code is used. PHP 5.4/5.5/5.6 branch has been updated to the latest, and will be kept up2date from now on. Fortunately, there are one more release for 5.3, I sent in a pull request for the PHP-5.3 branch on Github which updates sapi/litespeed code to the latest v6.6, it is the version has used in production for long time. https://github.com/php/php-src/pull/739 Hopefully, it is not too late. :-) Thanks, George Wang > Hi! > > > […] > Did not get any response for that - I guess everybody's too busy > discussing the number of the next PHP version :) But I think we still > need to release the final 5.3. So I plan to proceed this way: > > - Release the RC next week > - Release the final 5.3 version on August 14th. > > Any objections to this plan? > > If anybody has any way to reach Johannes and see if he wants to do it > himself later or is ok with the plan above, that'd be great. --- ## #76014 — johannes@php.net — 2014-07-24T14:40:44+00:00 URL: https://externals.io/message/74890#76014 · In reply to: #75984 > Hi, > > I have a request to include our latest sapi/litespeed V6.6 to the EOL > PHP 5.3 release. I thought it was EOL already. PHP 5.3 is in extended support and only receives security related fixes. In general people should use newer versions which have more bug fixes and are faster. I don't think these updates qualify. > We had some difficult to commit our LiteSpeed SAPI code into PHP > source repository before, so it is lagging behind our office release. What kind of issues? johannes --- ## #76075 — George Wang — 2014-07-24T22:23:49+00:00 URL: https://externals.io/message/74890#76075 · In reply to: #76014 > > > […] > PHP 5.3 is in extended support and only receives security related fixes. > In general people should use newer versions which have more bug fixes > and are faster. > I don't think these updates qualify. > > > […] > What kind of issues? A while back, I can only push change to master branch, but cannot push to other branches. So, master was updated to V6.4 last year, but other branches still stay at V5.5, which was released 4 years ago. I can push changes to other branches without problem now, all up2date now except the 5.3 branch. Best regards, George --- ## #76081 — Ferenc Kovacs — 2014-07-24T23:07:31+00:00 URL: https://externals.io/message/74890#76081 · In reply to: #76075 On Fri, Jul 25, 2014 at 12:23 AM, George Wang wrote: > > > > > […] > A while back, I can only push change to master branch, but cannot push to > other branches. > So, master was updated to V6.4 last year, but other branches still stay at > V5.5, which was released 4 years ago. > > I can push changes to other branches without problem now, all up2date now > except the 5.3 branch. > > Best regards, > George > > > -- > > > > as I mentioned previously when you reported the issue, based on the push reject message, you were trying to push to a subdirectory, where you didn't have access (probably had something not merged upwards in Zend/ or similar). -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #76144 — George Wang — 2014-07-25T20:55:40+00:00 URL: https://externals.io/message/74890#76144 · In reply to: #76081 > as I mentioned previously when you reported the issue, based on the > push reject message, you were trying to push to a subdirectory, where > you didn't have access (probably had something not merged upwards in > Zend/ or similar). All my changes were under sapi/litespeed directory, did the same thing to the master branch. Anyway, it is the past, let's deal with the present issue now. I just found that my commits to PHP-5.4.31 and PHP-5.5.15 branch have been voided, the result is that in final 5.4.31 and 5.5.15 release package, sapi/litespeed code is still the ancient V5.5 release, it is ridiculous! I got an email from Stas regarding my commits, I replied, but the end result is still like this. What is the procedure to make sure our latest sapi/litespeed release will be in the next release? Best regards, George Wang --- ## #76146 — Stas Malyshev — 2014-07-25T21:21:53+00:00 URL: https://externals.io/message/74890#76146 · In reply to: #76144 Hi! > I just found that my commits to PHP-5.4.31 and PHP-5.5.15 branch have > been voided, the result is that in final 5.4.31 and 5.5.15 release > package, sapi/litespeed code is still the ancient V5.5 release, it is > ridiculous! No, it is not ridiculous, it is the release process. The three-number branches are release branches, and no commits but by the RMs should be done there. Moreover, even by the RMs the only commits that go there once the release is branched is either technical release commits (versions, NEWS, etc.) or urgent high-profile security fixes which could not be done in development branches, or other exceptional commits (like somebody discovering at the last moment Windows build is broken). In general, once the release branch is created, it is frozen except for urgent fixes, RC fixes/reverts and other exceptional cases. The decision of which commits to include is by the RM of the branch. The regular commits go into development branches - PHP-5.4, PHP-5.5, etc. I've sent you an email to verify if it is not an urgent commit, but both from review and from your answers it was clear that it was not, and there's no compelling reason to override regular release flow for it. Thus, these commits were not included into releases that were already well under way. > What is the procedure to make sure our latest sapi/litespeed release > will be in the next release? Creating a pull request and after review etc. committing it to the development branches - PHP-5.4, PHP-5.5, etc. There's more info here: https://wiki.php.net/vcs/gitworkflow In the future, I would recommend to ask on the list if the procedure is not clear. I understand there was a lot of change in how PHP release process works in the last couple of years, and not everybody may be up to date with it. Please ask and we will answer. We have docs, we have guides and we have this list where there are a number of people who can explain how to do things right. We've outgrown the situation of cowboy release management, we have a process now, which has been working pretty well so far. I am sorry that it caused your frustration, but be assured your changes are not lost and will be released in the next version in accordance to the regular release process. I would also encourage you to update NEWS files for the release branches from 5.4 up to reflect your changes. The changes are always made to the topmost release in the NEWS file. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ --- ## #76148 — George Wang — 2014-07-25T22:24:11+00:00 URL: https://externals.io/message/74890#76148 · In reply to: #76146 All right, looks like it is my fault not making the reply sounds critical enough. It pretty much make all third party php-litespeed rpms useless, only causes trouble and confusion for LiteSpeed users. Maybe the release branches should be only open to the RMs, save everyone time and efforts and force to follow the procedure. So, now moving forward, the code should be in PHP-5.4/5.5/5.6 branches already, I will update NEWS files in 5.4/5.5/5.6 branches, anything else? I want to make sure the LiteSpeed SAPI code is up2date in next release. Best regards, George Wang > Hi! > > > […] > No, it is not ridiculous, it is the release process. The three-number > branches are release branches, and no commits but by the RMs should be > done there. Moreover, even by the RMs the only commits that go there > once the release is branched is either technical release commits > (versions, NEWS, etc.) or urgent high-profile security fixes which could > not be done in development branches, or other exceptional commits (like > somebody discovering at the last moment Windows build is broken). > > In general, once the release branch is created, it is frozen except for > urgent fixes, RC fixes/reverts and other exceptional cases. The decision > of which commits to include is by the RM of the branch. > > The regular commits go into development branches - PHP-5.4, PHP-5.5, > etc. I've sent you an email to verify if it is not an urgent commit, but > both from review and from your answers it was clear that it was not, and > there's no compelling reason to override regular release flow for it. > Thus, these commits were not included into releases that were already > well under way. > > > […] > Creating a pull request and after review etc. committing it to the > development branches - PHP-5.4, PHP-5.5, etc. There's more info here: > https://wiki.php.net/vcs/gitworkflow > > In the future, I would recommend to ask on the list if the procedure is > not clear. I understand there was a lot of change in how PHP release > process works in the last couple of years, and not everybody may be up > to date with it. Please ask and we will answer. We have docs, we have > guides and we have this list where there are a number of people who can > explain how to do things right. We've outgrown the situation of cowboy > release management, we have a process now, which has been working pretty > well so far. I am sorry that it caused your frustration, but be assured > your changes are not lost and will be released in the next version in > accordance to the regular release process. > > I would also encourage you to update NEWS files for the release branches > from 5.4 up to reflect your changes. The changes are always made to the > topmost release in the NEWS file. --- ## #76150 — Ferenc Kovacs — 2014-07-25T22:30:55+00:00 URL: https://externals.io/message/74890#76150 · In reply to: #76148 Hi George, is there any reason why seemingly you never read my original mail about those branches beeing off-limit and those commit gonna be reverted? http://news.php.net/php.cvs/79411 ps: we prefer bottom-posting on the php.net lists, and that hasn't changed in the last couple of years. On Sat, Jul 26, 2014 at 12:24 AM, George Wang wrote: > All right, looks like it is my fault not making the reply sounds critical > enough. It pretty much make all third party php-litespeed rpms useless, > only causes trouble and confusion for LiteSpeed users. > > Maybe the release branches should be only open to the RMs, save everyone > time and efforts and force to follow the procedure. > > So, now moving forward, the code should be in PHP-5.4/5.5/5.6 branches > already, I will update NEWS files in 5.4/5.5/5.6 branches, anything else? I > want to make sure the LiteSpeed SAPI code is up2date in next release. > > Best regards, > George Wang > > > > > > > > > […] > > -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #76151 — Stas Malyshev — 2014-07-25T22:33:38+00:00 URL: https://externals.io/message/74890#76151 · In reply to: #76148 Hi! > All right, looks like it is my fault not making the reply sounds > critical enough. It pretty much make all third party php-litespeed rpms > useless, only causes trouble and confusion for LiteSpeed users. I'm not sure what changed with the last php release - the old code was there for a long time, so why 5.4.31 was critical while 5.4.30 was not? > So, now moving forward, the code should be in PHP-5.4/5.5/5.6 branches > already, I will update NEWS files in 5.4/5.5/5.6 branches, anything > else? I want to make sure the LiteSpeed SAPI code is up2date in next > release. Nothing else, just test the RC when they will be announced (in 2 weeks, the releases work in 2-week cycles, RC then GA) and see it works well for you. If it does, everything is fine and the release will be out in another 2 weeks. If not, alert the RMs ASAP and we'll try to fix it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ --- ## #76284 — George Wang — 2014-07-30T19:11:49+00:00 URL: https://externals.io/message/74890#76284 · In reply to: #76150 Hi Ferenc, > is there any reason why seemingly you never read my original mail > about those branches beeing off-limit and those commit gonna be reverted? > http://news.php.net/php.cvs/79411 That's my fault due to how my email filters was configured. Just a suggestion to make the collaboration better. After all it is mainly due to my unfamiliarity with the releasing process, it costs not only me but others' precious time to deal with it. It could be avoided if my cherry-picks are declined with message like "please contact the release master." > > ps: we prefer bottom-posting on the php.net lists, > and that hasn't changed in the last couple of years. Sorry, will do that from now on. Best regards, George Wang --- Next page: https://externals.io/message/74890.md?page=2