Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89342
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain telia.com from 81.236.60.156 cause and error)
To: Anatol Belski <anatol.php@belski.net>,
 'Rasmus Lerdorf' <rasmus@lerdorf.com>,
 'Anthony Ferrara' <ircmaxell@gmail.com>, 'Zeev Suraski' <zeev@zend.com>
References: <CAAyV7nG9E-7STWq2Hpe=y5Uf0nWzGMhka+FUX1p1FVNtYNVTJQ@mail.gmail.com>
 <112FFBCD-8445-40BC-B92F-3A97D3E97C4C@zend.com>
 <CAAyV7nE0bQba3Wr2yi8FbtDfDA=8ZSFz9dbQG5uZ+eF9bick2A@mail.gmail.com>
 <56523F74.9040708@lerdorf.com> <06a601d125c0$99d5cfd0$cd816f70$@belski.net>
Cc: PHP internals <internals@lists.php.net>
Message-ID: <56535E5C.6060600@telia.com>
Date: Mon, 23 Nov 2015 19:43:40 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <06a601d125c0$99d5cfd0$cd816f70$@belski.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] INDRECT in arrays causes count() to become
 unpredictable
From: bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)

Den 2015-11-23 kl. 08:28, skrev Anatol Belski:
> Hi,
>
>> -----Original Message-----
>> From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]
>> Sent: Sunday, November 22, 2015 11:20 PM
>> To: Anthony Ferrara <ircmaxell@gmail.com>; Zeev Suraski <zeev@zend.com>
>> Cc: internals@lists.php.net
>> Subject: Re: [PHP-DEV] INDRECT in arrays causes count() to become
>> unpredictable
>>
>> On 11/22/2015 06:18 AM, Anthony Ferrara wrote:
>>> Zeev,
>>>
>>> On Sat, Nov 21, 2015 at 11:52 PM, Zeev Suraski <zeev@zend.com> wrote:
>>>>> On 22 בנוב׳ 2015, at 0:47, Anthony Ferrara <ircmaxell@gmail.com> wrote:
>>>>>
>>>>> I think this is significant enough to be a blocker to gold and that
>>>>> we should fix it prior to release.
>>>>>
>>>>> Thoughts?
>>>>>
>>>> IMHO, unless we think fixing this would require breaking binary compatibility
>> (which I don't think is the case) - this shouldn't block 7.0.0.  7.0.0 is a lot more
>> about getting people to start paying attention to 7.0 and start testing their
>> codebase against it - finding both the incompatibilities in their code and,
>> undoubtedly - the bugs we failed to find.  I wish we could say this would be the
>> last issue we find in 7.0, but I think we can all agree it's wishful thinking...
>>> Consider that Distros may very well pick whatever we call stable for
>>> LTS releases. Meaning that non-critical (crash/security) bugs that we
>>> miss may wind up living on for a VERY long time. If we don't intend .0
>>> to be stable, then what's the point of versioning in the first place?
>>>
>>> Xinchen,
>>>
>>> Very interesting on the fix. I do think it's important for this to
>>> land with 7, but at least we can have the discussion.
>> I agree with Zeev here and I had a chat with Anatol about this tonight.
>> This is a .0.0 release. Nobody is going to take a .0.0 and push it straight to
>> production. And it is not going to part of any sort of LTS distro either. It's not like
>> LTS distros don't pick up point releases.
>> There is no way we will go 2 weeks without finding something for quite a while
>> still which can drag things out indefinitely. The question is whether this is
>> significant enough to postpone further. Personally I don't think it is. Let's get
>> 7.0.0 out the door and get ourselves on track for regular point releases without
>> any of this "perfect-release"
>> stress.
>>
>  From what I was merging for 7.0.0, I see that there are quite some primitive bug fixes, a couple of non critical 7.0 bugs and 2 bugs merged up from 5.6. The issue with the symtable counter stands at some point around the critical border. I personally would see it as not crossing that border.
>
> So based on this, I'd rather go by releasing. The bug list after RC7 looks pretty much like a regular patch release, or even better. Comparing to RC6 where it was started to be tested obviously some more intensively, RC7 looks more like lost attention. We could go with more RC, sure. However in that case IMO we would catch bugs at very low speed with no guarantee we have a good thing at the end when we "think" it's good. This will cause us to defer things for much longer time. Releasing on 26th (or on 3rd with respect to Thanksgiving, if there are still strong concerns) were IMHO convenient for this reasons.
>
> People that don't test RC won't start to test any later RC anyway. People that don't test RC will start to use  GA and that will lead to bug reports, in any case. So IMHO at this point we are good enough to do the first release with all the known bugs fixed, with the knowledge that no critical bugs are present, with the knowledge that community projects like Drupal 8, Symfony, etc. report the green tests, and with intention to get people waiting for GA involved.
>
> Regards
>
> Anatol
Hi,

To give some feedback on our needs for a GA release of 7.0 is:
- Having a GA out is a strong incentive for our ISP to deploy 7.0 on our 
server.
   I believe that they have done some work to integrate 7.0 in their 
environment
   but nothing is yet available for us as a customer.
- Having 7.0 deployed on our server means we can start testing on the 
server.
   Of course we can spend time testing & porting on laptops but as long 
as we
   don't know when 7.0 is available we don't want to work to much in 
advance.
- I expect it would take 1 - 3 months to port our application to 7.0 and 
given
   that our ISP has maintenance windows once a month I would expect us to
   deploy on a 7.0.x version.
- A quality stamp for us that 7.0 is good enough is e.g. the passed 
tests for
   Drupal 8, which gives confidence.

So good luck with having a release out before christmas (3/12), you have all
done a terrific job! In Swedish I would call the coming 7.0 a 
"Kioskvältare" :-)

Regards //Björn

PS Can add that our existing application would run in parallel on PHP 5.