Re: [PHP-DEV] 7.0.0 release

[Ferenc Kovacs]

On Tue, Nov 24, 2015 at 5:07 PM, guilhermebla...@gmail.com <
guilhermebla...@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

Re: [PHP-DEV] 7.0.0 release

[Rafael Dohms]

On Mon, Nov 23, 2015 at 10:10 PM, Anatol Belski  wrote:

>
> 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 

Re: [PHP-DEV] 7.0.0 release

[Julien Pauli]

On Tue, Nov 24, 2015 at 7:27 AM, Zeev Suraski  wrote:
>
>> On 24 בנוב׳ 2015, at 7:18, Davey Shafik  wrote:
>>
>> On Tue, Nov 24, 2015 at 1:00 AM, Sebastian Bergmann 
>> wrote:
>>
 On 11/23/2015 10:10 PM, Anatol Belski wrote:

 c) do RC8, release on 3rd, expect there are no bugs come in
>>>
>>> +1
>>
>>
>> +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.

+1

We have to take care of December, 3rd is OK, later can be a problem
(Xmas approaching, etc...)


Julien

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 7.0.0 release

[Xinchen Hui]

Hey:

On Tue, Nov 24, 2015 at 7:57 PM, Leigh  wrote:

> On 23 November 2015 at 21:10, Anatol Belski  wrote:
>
> > 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.
>
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/

Re: [PHP-DEV] 7.0.0 release

[Leigh]

On 23 November 2015 at 21:10, Anatol Belski  wrote:

> 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

Re: [PHP-DEV] 7.0.0 release

[David Zuelke]

On 24.11.2015, at 12:57, Leigh  wrote:

> 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.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 7.0.0 release

[Bishop Bettini]

On Mon, Nov 23, 2015 at 4:10 PM, Anatol Belski  wrote:

> 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. :)

Re: [PHP-DEV] 7.0.0 release

[guilhermebla...@gmail.com]

+1 on (a)

It's perfectly normal to have issues fixed between last RC and GA.

[]s,

On Tue, Nov 24, 2015 at 10:51 AM, Bishop Bettini  wrote:

> On Mon, Nov 23, 2015 at 4:10 PM, Anatol Belski 
> wrote:
>
> > 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. :)
>



-- 
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

Re: [PHP-DEV] 7.0.0 release

[Good guy]

On 23/11/2015 21:10, Anatol Belski wrote:

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/




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 7.0.0 release

[Sebastian Bergmann]

On 11/23/2015 10:10 PM, Anatol Belski wrote:

c) do RC8, release on 3rd, expect there are no bugs come in


 +1

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 7.0.0 release

[Davey Shafik]

On Tue, Nov 24, 2015 at 1:00 AM, Sebastian Bergmann 
wrote:

> On 11/23/2015 10:10 PM, Anatol Belski wrote:
>
>> c) do RC8, release on 3rd, expect there are no bugs come in
>>
>
>  +1


+1

Re: [PHP-DEV] 7.0.0 release

[Joe Watkins]

+1 C

On Tue, Nov 24, 2015 at 6:18 AM, Davey Shafik  wrote:

> On Tue, Nov 24, 2015 at 1:00 AM, Sebastian Bergmann 
> wrote:
>
> > On 11/23/2015 10:10 PM, Anatol Belski wrote:
> >
> >> c) do RC8, release on 3rd, expect there are no bugs come in
> >>
> >
> >  +1
>
>
> +1
>

Re: [PHP-DEV] 7.0.0 release

[Zeev Suraski]

> On 24 בנוב׳ 2015, at 7:18, Davey Shafik  wrote:
> 
> On Tue, Nov 24, 2015 at 1:00 AM, Sebastian Bergmann 
> wrote:
> 
>>> On 11/23/2015 10:10 PM, Anatol Belski wrote:
>>> 
>>> c) do RC8, release on 3rd, expect there are no bugs come in
>> 
>> +1
> 
> 
> +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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 7.0.0 release

[David Zuelke]

On 23.11.2015, at 22:10, Anatol Belski  wrote:

> 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 ;)



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 7.0.0 release

[Ferenc Kovacs]

On Mon, Nov 23, 2015 at 11:45 PM, Good guy  wrote:

> On 23/11/2015 21:10, Anatol Belski wrote:
>
>> 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/
>
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
http://windows.php.net/qa

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] 7.0.0 release

[Jan Ehrhardt]

Good guy in php.internals (Mon, 23 Nov 2015 22:45:38 +):
>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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 7.0.0 release

[Stanislav Malyshev]

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
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 7.0.0 release

[Derick Rethans]

On November 23, 2015 10:10:37 PM GMT+01:00, Anatol Belski  
wrote:
>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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php