7.0.0 release

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