# 7.0.0 release - Thread: https://externals.io/message/89352 - Original archive: https://news-web.php.net/php.internals/89352 - Started by Anatol Belski on 2015-11-23T21:10:37+00:00 - Messages: 19 - 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 --- ## #89352 — Anatol Belski — 2015-11-23T21:10:37+00:00 URL: https://externals.io/message/89352#89352 Hi, it is sad to see that the discussion went in the direction it went, but I'm glad to have missed that being away all day and at the end of it realizing my mail server messed up. Please lets get the tone down and discuss factually! I would like to turn back to the point I was depicting in my first mail - the current stuff destined (including the bug fix for the sym table issue ofc) into the 7.NEXT looks pretty much like a set of fixes for a patch version. It is enough to go through the NEWS of 5.5 or 5.6 and compare to realize that. In aforementioned NEWS files, several bugs can be evaluated even as more critical as the subject caused the discussion. An accusation that the intention to deliver this as GA has the purpose of something bad has therefore just no objective base. In opposite - looking like a patch release is a testimony that 7.0 is ripe enough to enter the routine life cycle. Today, we have a set of patches that can deliver a stable 7.0.0 to the today's knowledge (remember also 5.x NEWS files in conjunction with this). I probably just repeat what I was telling - any known app compatible with 7.0.0 today has the tests green today. To comply with the above and the definition of stable. Now, with 7.0.0. The gap between 5 and 7 is big, the number of ported apps is small, same with the number of developers using it. How do we get the wheel to spin? Please think strategically. How do we get the 7.0.0 GA to have the gap to be the same as between some adjacent PHP5 minor releases? Short - one can delay. There is a group of people who wants it to be done. What does that mean? That means, less usage, less testing, slower bug discovery. Even shorter - one can release. What does that mean? That means that we are on the track, more apps are getting ported, more people use it, more bugs we fix - we are stable. Just to remind - the RC7 was caused but the exact reason that it were impossible and extremely bad to deliver an untested lot of various and partially bad issues. And that was suitable. That's why also other two weeks was taken. It is quite pointless to have a one week RC, because the feedback on that is negligible and consequently no real bugs are catched. It doesn't comply with the expressed intention to validate the bug fix. Now, it is of course the matter of the definition, but issuing one more RC for the bugs that are don't even stand near the cause of the RC7 doesn't sound like an appropriate action. Either the bugs are heavy weight and the fixes need to be properly tested, or they are not. Except one turns back to the thesis that there should be no bugs. So in the end, a solution is wanted. I don't think any opinion is allowed to be ignored for such a topic. So options a) release on 26th including all known bug fixes b) do RC8, assume there are no bugs, so target 10th for RTM c) do RC8, release on 3rd, expect there are no bugs come in d) continue issuing release candidates till it's stable enough (needs definition of stable and probably an RFC) I would really ask to reach a consent on either a) or c). IMO, the options b) and d) are the direct road to curbing 7.0.0. There is no hurry to release just to release, but it is definitely harmful to slow down the rise. Thanks Anatol --- ## #89353 — Stanislav Malyshev — 2015-11-23T21:21:18+00:00 URL: https://externals.io/message/89352#89353 · In reply to: #89352 Hi! > So in the end, a solution is wanted. I don't think any opinion is > allowed to be ignored for such a topic. So options > > a) release on 26th including all known bug fixes > b) do RC8, assume there are no bugs, so target 10th for RTM > c) do RC8, release on 3rd, expect there are no bugs come in > d) continue issuing release candidates till it's stable enough (needs definition of stable and probably an RFC) > > I would really ask to reach a consent on either a) or c). IMO, the options b) and d) are the direct road to curbing 7.0.0. There is no hurry to release just to release, but it is definitely harmful to slow down the rise. I like option c. The count bug looks like it could break a bunch of apps, so releasing with it is possible but not ideal. Since we have a fix for it I'd just wait another week. Not releasing on holiday is also a plus in my book (not enough by itself to wait another week but in conjunction with the actual serious bug in my opinion it tips the scale). P.S. of course I also assume if somebody discovers huge bug before the 3rd we'd have to reconsider, but otherwise we should assume RC8 is the future GA tag. -- Stas Malyshev smalyshev@gmail.com --- ## #89354 — Derick Rethans — 2015-11-23T21:46:26+00:00 URL: https://externals.io/message/89352#89354 · In reply to: #89352 >Hi, > >it is sad to see that the discussion went in the direction it went, but >I'm glad to have missed that being away all day and at the end of it >realizing my mail server messed up. Please lets get the tone down and >discuss factually! > >I would like to turn back to the point I was depicting in my first mail >- the current stuff destined (including the bug fix for the sym table >issue ofc) into the 7.NEXT looks pretty much like a set of fixes for a >patch version. It is enough to go through the NEWS of 5.5 or 5.6 and >compare to realize that. In aforementioned NEWS files, several bugs can >be evaluated even as more critical as the subject caused the >discussion. An accusation that the intention to deliver this as GA has >the purpose of something bad has therefore just no objective base. In >opposite - looking like a patch release is a testimony that 7.0 is ripe >enough to enter the routine life cycle. > >Today, we have a set of patches that can deliver a stable 7.0.0 to the >today's knowledge (remember also 5.x NEWS files in conjunction with >this). I probably just repeat what I was telling - any known app >compatible with 7.0.0 today has the tests green today. > >To comply with the above and the definition of stable. Now, with >7.0.0. The gap between 5 and 7 is big, the number of >ported apps is small, same with the number of developers using it. How >do we get the wheel to spin? Please think strategically. How do we get >the 7.0.0 GA to have the gap to be the same as between some adjacent >PHP5 minor releases? > >Short - one can delay. There is a group of people who wants it to be >done. What does that mean? That means, less usage, less testing, slower >bug discovery. Even shorter - one can release. What does that mean? >That means that we are on the track, more apps are getting ported, more >people use it, more bugs we fix - we are stable. > >Just to remind - the RC7 was caused but the exact reason that it were >impossible and extremely bad to deliver an untested lot of various and >partially bad issues. And that was suitable. That's why also other two >weeks was taken. It is quite pointless to have a one week RC, because >the feedback on that is negligible and consequently no real bugs are >catched. It doesn't comply with the expressed intention to validate the >bug fix. Now, it is of course the matter of the definition, but issuing >one more RC for the bugs that are don't even stand near the cause of >the RC7 doesn't sound like an appropriate action. Either the bugs are >heavy weight and the fixes need to be properly tested, or they are >not. Except one turns back to the thesis that there should be no bugs. > >So in the end, a solution is wanted. I don't think any opinion is >allowed to be ignored for such a topic. So options > >a) release on 26th including all known bug fixes >b) do RC8, assume there are no bugs, so target 10th for RTM >c) do RC8, release on 3rd, expect there are no bugs come in >d) continue issuing release candidates till it's stable enough (needs >definition of stable and probably an RFC) > >I would really ask to reach a consent on either a) or c). IMO, the >options b) and d) are the direct road to curbing 7.0.0. There is no >hurry to release just to release, but it is definitely harmful to slow >down the ris... I think a is best but c works too, although it makes no sense really... cheers, Derick, Nikita --- ## #89357 — Good guy — 2015-11-23T22:45:38+00:00 URL: https://externals.io/message/89352#89357 · In reply to: #89352 > Hi, > > it is sad to see that the discussion went in the direction it went, but I'm glad to have missed that being away all day and at the end of it realizing my mail server messed up. Please lets get the tone down and discuss factually! > > I would like to turn back to the point I was depicting in my first mail - the current stuff destined (including the bug fix for the sym table issue ofc) into the 7.NEXT looks pretty much like a set of fixes for a patch version. It is enough to go through the NEWS of 5.5 or 5.6 and compare to realize that. In aforementioned NEWS files, several bugs can be evaluated even as more critical as the subject caused the discussion. An accusation that the intention to deliver this as GA has the purpose of something bad has therefore just no objective base. In opposite - looking like a patch release is a testimony that 7.0 is ripe enough to enter the routine life cycle. > > Today, we have a set of patches that can deliver a stable 7.0.0 to the today's knowledge (remember also 5.x NEWS files in conjunction with this). I probably just repeat what I was telling - any known app compatible with 7.0.0 today has the tests green today. > > To comply with the above and the definition of stable. Now, with > 7.0.0. The gap between 5 and 7 is big, the number of > ported apps is small, same with the number of developers using it. How > do we get the wheel to spin? Please think strategically. How do we get the 7.0.0 GA to have the gap to be the same as between some adjacent PHP5 minor releases? > > Short - one can delay. There is a group of people who wants it to be done. What does that mean? That means, less usage, less testing, slower bug discovery. Even shorter - one can release. What does that mean? That means that we are on the track, more apps are getting ported, more people use it, more bugs we fix - we are stable. > > Just to remind - the RC7 was caused but the exact reason that it were impossible and extremely bad to deliver an untested lot of various and partially bad issues. And that was suitable. That's why also other two weeks was taken. It is quite pointless to have a one week RC, because the feedback on that is negligible and consequently no real bugs are catched. It doesn't comply with the expressed intention to validate the bug fix. Now, it is of course the matter of the definition, but issuing one more RC for the bugs that are don't even stand near the cause of the RC7 doesn't sound like an appropriate action. Either the bugs are heavy weight and the fixes need to be properly tested, or they are not. Except one turns back to the thesis that there should be no bugs. > > So in the end, a solution is wanted. I don't think any opinion is allowed to be ignored for such a topic. So options > > a) release on 26th including all known bug fixes > b) do RC8, assume there are no bugs, so target 10th for RTM > c) do RC8, release on 3rd, expect there are no bugs come in > d) continue issuing release candidates till it's stable enough (needs definition of stable and probably an RFC) > > I would really ask to reach a consent on either a) or c). IMO, the options b) and d) are the direct road to curbing 7.0.0. There is no hurry to release just to release, but it is definitely harmful to slow down the rise. > > Thanks > > Anatol > > when is it available from Windows binaries download site? It still says this: 7 has no release http://windows.php.net/download/ --- ## #89359 — Jan Ehrhardt — 2015-11-23T23:37:05+00:00 URL: https://externals.io/message/89352#89359 · In reply to: #89357 Good guy in php.internals (Mon, 23 Nov 2015 22:45:38 +0000): >when is it available from Windows binaries download site? It still says >this: > >7 has no release 7 has no release, but RC7 is here: http://windows.php.net/qa/ -- Jan --- ## #89358 — Ferenc Kovacs — 2015-11-23T23:39:27+00:00 URL: https://externals.io/message/89352#89358 · In reply to: #89357 > > > > […] > > when is it available from Windows binaries download site? It still says > this: > > 7 has no release > > > http://windows.php.net/download/ > > > > > > -- > > > > http://windows.php.net/qa -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #89360 — David Zuelke — 2015-11-24T00:12:27+00:00 URL: https://externals.io/message/89352#89360 · In reply to: #89352 > So in the end, a solution is wanted. I don't think any opinion is allowed to be ignored for such a topic. So options > > a) release on 26th including all known bug fixes > b) do RC8, assume there are no bugs, so target 10th for RTM > c) do RC8, release on 3rd, expect there are no bugs come in > d) continue issuing release candidates till it's stable enough (needs definition of stable and probably an RFC) > > I would really ask to reach a consent on either a) or c). IMO, the options b) and d) are the direct road to curbing 7.0.0. There is no hurry to release just to release, but it is definitely harmful to slow down the rise. My vote (if it matters) goes for c) It also has the nice side effect of not clashing with ~Black Friday, and by next week, the "oh wow Wordpress just moved to Node.js" hype will have died down too, giving PHP 7 more of the attention it deserves ;) --- ## #89361 — Sebastian Bergmann — 2015-11-24T06:00:34+00:00 URL: https://externals.io/message/89352#89361 · In reply to: #89352 > c) do RC8, release on 3rd, expect there are no bugs come in +1 --- ## #89362 — Davey Shafik — 2015-11-24T06:18:43+00:00 URL: https://externals.io/message/89352#89362 · In reply to: #89361 On Tue, Nov 24, 2015 at 1:00 AM, Sebastian Bergmann wrote: > > > > […] > > +1 +1 --- ## #89363 — Joe Watkins — 2015-11-24T06:25:23+00:00 URL: https://externals.io/message/89352#89363 · In reply to: #89362 +1 C > On Tue, Nov 24, 2015 at 1:00 AM, Sebastian Bergmann > wrote: > > > […] > > > +1 --- ## #89364 — Zeev Suraski — 2015-11-24T06:27:13+00:00 URL: https://externals.io/message/89352#89364 · In reply to: #89362 > > > On Tue, Nov 24, 2015 at 1:00 AM, Sebastian Bergmann > wrote: > > > […] > > > +1 +1 With one important mod - of course there'll be bugs coming in. But much like you said, if they're the kind we see on the change log of every bug fix release we do (like between RC7 and RC8), let's not delay the release for them. Delaying the release further should be for truly disastrous bugs. Zeev --- ## #89365 — Julien Pauli — 2015-11-24T09:45:47+00:00 URL: https://externals.io/message/89352#89365 · In reply to: #89364 > > > […] > > +1 > > With one important mod - of course there'll be bugs coming in. But much like you said, if they're the kind we see on the change log of every bug fix release we do (like between RC7 and RC8), let's not delay the release for them. Delaying the release further should be for truly disastrous bugs. +1 We have to take care of December, 3rd is OK, later can be a problem (Xmas approaching, etc...) Julien --- ## #89366 — Rafael Dohms — 2015-11-24T10:02:44+00:00 URL: https://externals.io/message/89352#89366 · In reply to: #89352 > > a) release on 26th including all known bug fixes > b) do RC8, assume there are no bugs, so target 10th for RTM > c) do RC8, release on 3rd, expect there are no bugs come in > d) continue issuing release candidates till it's stable enough (needs > definition of stable and probably an RFC) > C would be ideal. Give everyone a chance to validate the count fix, plus its a nice date that does not leave Americans up in arms about turkeys and its way before christmas, very neutral ground -- Rafael Dohms PHP Evangelist and Community Leader http://doh.ms http://www.amsterdamphp.nl a) release on 26th including all known bug fixes > b) do RC8, assume there are no bugs, so target 10th for RTM > c) do RC8, release on 3rd, expect there are no bugs come in > d) continue issuing release candidates till it's stable enough (needs > definition of stable and probably an RFC) > > I would really ask to reach a consent on either a) or c). IMO, the options > b) and d) are the direct road to curbing 7.0.0. There is no hurry to > release just to release, but it is definitely harmful to slow down the rise. > > Thanks > > Anatol > I prefer a over c. As you said, we can deliver a stable and high quality 7.0.0 today. An RC period where you expect no bugs does not sound productive to me. We all know the "real testing" doesn't begin until it's released, and the best way to find what is left (things we have not found in over a year of development and testing), is to get more people looking at it. Delaying the release is actually delaying the discovery of bugs that affect real world applications that we do not have access to, and cannot test with. Many teams will not even start testing with 7 until it gets an official release. If something is found, it doesn't make the release any less high quality. Any bugs that would be found between now and the 3rd will still be found (and probably more), and they will still be fixed. The only difference would be a 0.0.1 version number. /2c --- ## #89372 — Xinchen Hui — 2015-11-24T12:33:30+00:00 URL: https://externals.io/message/89352#89372 · In reply to: #89367 Hey: > > > > […] > options > > […] > rise. > > […] > > I prefer a over c. > > As you said, we can deliver a stable and high quality 7.0.0 today. An RC > period where you expect no bugs does not sound productive to me. > > We all know the "real testing" doesn't begin until it's released, and the > best way to find what is left (things we have not found in over a year of > development and testing), is to get more people looking at it. > > Delaying the release is actually delaying the discovery of bugs that affect > real world applications that we do not have access to, and cannot test > with. Many teams will not even start testing with 7 until it gets an > official release. > I agree. I also go for a) thanks > > If something is found, it doesn't make the release any less high quality. > Any bugs that would be found between now and the 3rd will still be found > (and probably more), and they will still be fixed. The only difference > would be a 0.0.1 version number. > > /2c > -- Xinchen Hui @Laruence http://www.laruence.com/ --- ## #89373 — David Zuelke — 2015-11-24T13:20:34+00:00 URL: https://externals.io/message/89352#89373 · In reply to: #89367 > I prefer a over c. > > As you said, we can deliver a stable and high quality 7.0.0 today. An RC > period where you expect no bugs does not sound productive to me. That is exactly the point of an RC. No show-stoppers means you then roll the RC out as the golden version. Otherwise, another RC. Rinse and repeat. --- ## #89379 — Bishop Bettini — 2015-11-24T15:51:38+00:00 URL: https://externals.io/message/89352#89379 · In reply to: #89352 > a) release on 26th including all known bug fixes > b) do RC8, assume there are no bugs, so target 10th for RTM > c) do RC8, release on 3rd, expect there are no bugs come in > d) continue issuing release candidates till it's stable enough (needs > definition of stable and probably an RFC) > > I would really ask to reach a consent on either a) or c). IMO, the options > b) and d) are the direct road to curbing 7.0.0. There is no hurry to > release just to release, but it is definitely harmful to slow down the rise. > The little poll I sent yesterday in response to Phil's email has an even split. Question: Create an RC for this count($array) fix? Responses: 26 for, 26 against http://poll.pollcode.com/92997454_result?v Maybe all it says is the community is split, and we won't reach consensus. So while I'm +1 on (c), I defer to the wisdom and guidance of our RMs. :) --- ## #89381 — guilhermeblanco@gmail.com — 2015-11-24T16:07:19+00:00 URL: https://externals.io/message/89352#89381 · In reply to: #89379 +1 on (a) It's perfectly normal to have issues fixed between last RC and GA. []s, > On Mon, Nov 23, 2015 at 4:10 PM, Anatol Belski > wrote: > > > […] > options > > […] > rise. > > […] > > The little poll I sent yesterday in response to Phil's email has an even > split. > > Question: Create an RC for this count($array) fix? > Responses: 26 for, 26 against > http://poll.pollcode.com/92997454_result?v > > Maybe all it says is the community is split, and we won't reach consensus. > > So while I'm +1 on (c), I defer to the wisdom and guidance of our RMs. :) > -- Guilherme Blanco MSN: guilhermeblanco@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada --- ## #89407 — Ferenc Kovacs — 2015-11-25T12:37:01+00:00 URL: https://externals.io/message/89352#89407 · In reply to: #89381 On Tue, Nov 24, 2015 at 5:07 PM, guilhermeblanco@gmail.com < guilhermeblanco@gmail.com> wrote: > +1 on (a) > > It's perfectly normal to have issues fixed between last RC and GA. > > []s, it's not a clear cut. you can get away with doing that but the point of the RCs is that allow the general public to test and spot problems before the GA release. if your GA isn't made from the last RC there is a chance that those changes introduced since the last RC have problems which the general public did not have a chance to find and report. for the php project we prefer having the GA releases done from the RC and we usually more strict about this when preparing the .0 release. (for the record this is also how golden master originally was defined: http://techterms.com/definition/goldenmaster ) -- Ferenc Kovács @Tyr43l - http://tyrael.hu