Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:89352 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 22020 invoked from network); 23 Nov 2015 21:10:43 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Nov 2015 21:10:43 -0000 Authentication-Results: pb1.pair.com header.from=weltling@outlook.de; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=weltling@outlook.de; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain outlook.de designates 157.55.1.151 as permitted sender) X-PHP-List-Original-Sender: weltling@outlook.de X-Host-Fingerprint: 157.55.1.151 dub004-omc2s12.hotmail.com Received: from [157.55.1.151] ([157.55.1.151:54725] helo=DUB004-OMC2S12.hotmail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 52/0C-47837-1D083565 for ; Mon, 23 Nov 2015 16:10:42 -0500 Received: from DUB128-W22 ([157.55.1.137]) by DUB004-OMC2S12.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 23 Nov 2015 13:10:37 -0800 X-TMN: [emb7YkkJaWzK3ADXQbxiHEzwS68w+CsN] X-Originating-Email: [weltling@outlook.de] Message-ID: Content-Type: multipart/alternative; boundary="_2290f5d3-8e61-4ddf-9167-c7f63aa89fa4_" To: "internals@lists.php.net" Date: Mon, 23 Nov 2015 22:10:37 +0100 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 23 Nov 2015 21:10:37.0592 (UTC) FILETIME=[66895980:01D12633] Subject: 7.0.0 release From: weltling@outlook.de (Anatol Belski) --_2290f5d3-8e61-4ddf-9167-c7f63aa89fa4_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi=2C it is sad to see that the discussion went in the direction it went=2C but I= 'm glad to have missed that being away all day and at the end of it realizi= ng my mail server messed up. Please lets get the tone down and discuss fact= ually! I would like to turn back to the point I was depicting in my first mail - t= he current stuff destined (including the bug fix for the sym table issue of= c) into the 7.NEXT looks pretty much like a set of fixes for a patch versio= n. It is enough to go through the NEWS of 5.5 or 5.6 and compare to realize= that. In aforementioned NEWS files=2C several bugs can be evaluated even a= s more critical as the subject caused the discussion. An accusation that th= e intention to deliver this as GA has the purpose of something bad has ther= efore 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=2C we have a set of patches that can deliver a stable 7.0.0 to the to= day'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.=20 To comply with the above and the definition of stable. Now=2C with =0A= 7.0.0. The gap between 5 and 7 is big=2C the number of =0A= ported apps is small=2C same with the number of developers using it. How = =0A= 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?=20 Short - one can delay. There is a group of people who wants it to be done. = What does that mean? That means=2C less usage=2C less testing=2C slower bug= discovery. Even shorter - one can release. What does that mean? That means= that we are on the track=2C more apps are getting ported=2C more people us= e it=2C more bugs we fix - we are stable. Just to remind - the RC7 was caused but the exact reason that it were impos= sible 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 tak= en. It is quite pointless to have a one week RC=2C because the feedback on = that is negligible and consequently no real bugs are catched. It doesn't co= mply with the expressed intention to validate the bug fix. Now=2C it is of = course the matter of the definition=2C 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=2C or they are not. Except one turns back to the thesis= that there should be no bugs. So in the end=2C 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=2C assume there are no bugs=2C so target 10th for RTM c) do RC8=2C release on 3rd=2C expect there are no bugs come in d) continue issuing release candidates till it's stable enough (needs defin= ition of stable and probably an RFC) I would really ask to reach a consent on either a) or c). IMO=2C the option= s b) and d) are the direct road to curbing 7.0.0. There is no hurry to rel= ease just to release=2C but it is definitely harmful to slow down the rise. Thanks Anatol = --_2290f5d3-8e61-4ddf-9167-c7f63aa89fa4_--