Re: [PHP-DEV] PHP 8.0 branch cut - The Return

[Sara Golemon]

On Thu, Oct 8, 2020 at 2:49 AM Nikita Popov  wrote:

> At this point we have a number of PHP-8.1 only changes pending, so I think
> it would make sense to go ahead with the branch cut now. Any concerns with
> doing that today/tomorrow? (I don't think we need to synchronize this with
> the next release.)
>
>
Traditionally we've done that with a release (on an every other tuesday),
but there's no reason that /has to/ be the case.  No objections from me if
you want to just cut it.

-Sara

Re: [PHP-DEV] PHP 8.0 branch cut - The Return

[Nikita Popov]

On Mon, Sep 28, 2020 at 10:56 AM Gabriel Caruso 
wrote:

> Following Sara's email a couple of weeks ago, I come this week with a
> similar one:
>
> Next Tuesday, Sep 29th, has been marked on our calendars as the branch date
> for PHP-8.0 which would open master up for 8.1 targeted work.
>
> This would mean that bug fixes would need to include PHP-8.0 in their merge
> chain (meaning more work to merge 8.0 targeted fixes).
>
> Please let Sara and I know how you feel about this date. We can see that
> master is still quite active, especially with
> https://github.com/php/php-tasks/issues/18 and
> https://github.com/php/php-tasks/issues/16, and we don't wish to make the
> work to stabilize
> the 8.0 release any more difficult than it has to be.
>
> Thanks,
>

At this point we have a number of PHP-8.1 only changes pending, so I think
it would make sense to go ahead with the branch cut now. Any concerns with
doing that today/tomorrow? (I don't think we need to synchronize this with
the next release.)

Nikita

Re: [PHP-DEV] PHP 8.0 branch cut - The Return

[Sara Golemon]

On Tue, Sep 29, 2020 at 5:00 PM Gabriel Caruso 
wrote:
> I'm gonna borrow Nikita's idea, and tag RC1 today without cutting the
PHP-8.0 branch.
>
Late to the conversation, but I stand by Gabriel's call to proceed with
release names as-is, but defer branching till RC2.

To be clear, we're calling the ABI frozen from this release (RC1).  Changes
to the ABI should be duly considered and rejected if not essential.

The user-facing API (of particular concern to named parameters) may be
considered still (partially) fluid up until RC4, but please take every
measure to finalize these changes sooner rather than later.  We want
external testing to be meaningful, and that only happens with a stable API.

At this time, we should consider RC2 as a firm branch cut date. If we still
have a high enough volume of changes going into 8.0 to make merging
problematic, then we have a more fundamental issue with the release and it
will be time to consider delaying GA through the holidays. _Nobody_ wants
that.

Thank you to folks working on the JIT for reaching a stable point for
release, and thank you to the folks working on named parameters for their
continued dedication to getting our public API into a solid state.
And of course, thank you to everyone who's been contributing to PHP for
both this release and the 25 years of our storied history.  I treasure you
all. ❤️

-Sara

Re: [PHP-DEV] PHP 8.0 branch cut - The Return

[Gabriel Caruso]

On Tue, 29 Sep 2020 at 14:29, Nikita Popov  wrote:

> On Tue, Sep 29, 2020 at 2:18 PM Remi Collet  wrote:
>
> > Le 29/09/2020 à 11:55, Máté Kocsis a écrit :
> >
> > > Personally, I think releasing RC1 is realistic now, since parameter
> > > names in the most important extensions (- ext/spl) have already been
> > > reviewed.
> >
> > I agree, nice to have "internal" API freezed, and released
> > to give extension maintainer enough time
> >
> > I think parameter names (public API) still can change in next RC
> > as named parameters are not yet widely used.
> >
> > If we choose for another beta, this probably means we'll have
> > to move GA date by 2 weeks (to keep same RC time, already reduced).
> >
>
> I'm also fine with doing the ABI freeze already now. I don't have any ABI
> impacting work planned, the attributes/strict_types changes were the last
> bit.
>
> In that case:
>  * Bump ABI numbers and tag RC1 today
>  * Continue working on parameter names afterwards
>  * Cut the PHP-8.0 branch sometime in the next two weeks
>
> Nikita
>

I'm gonna borrow Nikita's idea, and tag RC1 today without cutting the
PHP-8.0 branch.

Thanks everyone for your input.

Re: [PHP-DEV] PHP 8.0 branch cut - The Return

[G. P. B.]

On Tue, 29 Sep 2020 at 13:44, Dik Takken  wrote:

> On 29-09-2020 14:17, Remi Collet wrote:
> > I think parameter names (public API) still can change in next RC
> > as named parameters are not yet widely used.
>
> How about warning promotions? My own impression is that we are 99% there
> but not quite 100%.
>
> Regards,
> Dik Takken
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php


Other than my outstanding PR about the PGSQL extension [1] I think we
covered 99.5% of them.
And I'm not sure even if we get another 2 weeks (or even months) we
wouldn't still find a missed
edge case past this date.

As such I think doing a late tag today should be fine.
Would have wished to clear up my PR earlier but I had some unrelated issues
come up (namely no
electricity until 20minutes ago).

Best regards

George P. Banyard

[1] https://github.com/php/php-src/pull/6226

Re: [PHP-DEV] PHP 8.0 branch cut - The Return

[Dik Takken]

On 29-09-2020 14:17, Remi Collet wrote:
> I think parameter names (public API) still can change in next RC
> as named parameters are not yet widely used.

How about warning promotions? My own impression is that we are 99% there
but not quite 100%.

Regards,
Dik Takken

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

Re: [PHP-DEV] PHP 8.0 branch cut - The Return

[Nikita Popov]

On Tue, Sep 29, 2020 at 2:18 PM Remi Collet  wrote:

> Le 29/09/2020 à 11:55, Máté Kocsis a écrit :
>
> > Personally, I think releasing RC1 is realistic now, since parameter
> > names in the most important extensions (- ext/spl) have already been
> > reviewed.
>
> I agree, nice to have "internal" API freezed, and released
> to give extension maintainer enough time
>
> I think parameter names (public API) still can change in next RC
> as named parameters are not yet widely used.
>
> If we choose for another beta, this probably means we'll have
> to move GA date by 2 weeks (to keep same RC time, already reduced).
>

I'm also fine with doing the ABI freeze already now. I don't have any ABI
impacting work planned, the attributes/strict_types changes were the last
bit.

In that case:
 * Bump ABI numbers and tag RC1 today
 * Continue working on parameter names afterwards
 * Cut the PHP-8.0 branch sometime in the next two weeks

Nikita

Re: [PHP-DEV] PHP 8.0 branch cut - The Return

[Remi Collet]

Le 29/09/2020 à 11:55, Máté Kocsis a écrit :

> Personally, I think releasing RC1 is realistic now, since parameter
> names in the most important extensions (- ext/spl) have already been
> reviewed.

I agree, nice to have "internal" API freezed, and released
to give extension maintainer enough time

I think parameter names (public API) still can change in next RC
as named parameters are not yet widely used.

If we choose for another beta, this probably means we'll have
to move GA date by 2 weeks (to keep same RC time, already reduced).



Regards,
Remi

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

Re: [PHP-DEV] PHP 8.0 branch cut - The Return

[Máté Kocsis]

Thank you for the question!

If I may give my opinion, I'd wait with the branch cut, simply because
merging to 2 branches would make
contributing more time consuming for me, especially when there are multiple
PRs/day to merge,
and when we have a close deadline.

I don't know whether it's possible to release RC1 (and freeze ABI) without
a branch cut, but I'd be ok
with this as well, so that we would have an extra 1-2 weeks to finish the
majority of the parameter renames
without an additional merging overhead. Personally, I think releasing RC1
is realistic now, since parameter
names in the most important extensions (- ext/spl) have already been
reviewed.

Regards,
Máté

Re: [PHP-DEV] PHP 8.0 branch cut - The Return

[Dmitry Stogov]

Hi,

This is fine to me.
I stopped active JIT development, and going to do only fixes and may be
minor improvements.

Thanks. Dmitry.

On Mon, Sep 28, 2020 at 11:56 AM Gabriel Caruso 
wrote:

> Following Sara's email a couple of weeks ago, I come this week with a
> similar one:
>
> Next Tuesday, Sep 29th, has been marked on our calendars as the branch date
> for PHP-8.0 which would open master up for 8.1 targeted work.
>
> This would mean that bug fixes would need to include PHP-8.0 in their merge
> chain (meaning more work to merge 8.0 targeted fixes).
>
> Please let Sara and I know how you feel about this date. We can see that
> master is still quite active, especially with
> https://github.com/php/php-tasks/issues/18 and
> https://github.com/php/php-tasks/issues/16, and we don't wish to make the
> work to stabilize
> the 8.0 release any more difficult than it has to be.
>
> Thanks,
>

Re: [PHP-DEV] PHP 8.0 branch cut - The Return

[Nikita Popov]

On Mon, Sep 28, 2020 at 10:56 AM Gabriel Caruso 
wrote:

> Following Sara's email a couple of weeks ago, I come this week with a
> similar one:
>
> Next Tuesday, Sep 29th, has been marked on our calendars as the branch date
> for PHP-8.0 which would open master up for 8.1 targeted work.
>
> This would mean that bug fixes would need to include PHP-8.0 in their merge
> chain (meaning more work to merge 8.0 targeted fixes).
>
> Please let Sara and I know how you feel about this date. We can see that
> master is still quite active, especially with
> https://github.com/php/php-tasks/issues/18 and
> https://github.com/php/php-tasks/issues/16, and we don't wish to make the
> work to stabilize
> the 8.0 release any more difficult than it has to be.
>

Current status:

The warning promotion is essentially complete. On
https://github.com/php/php-tasks/issues/18 everything is ticked or has a PR
that will land by tomorrow.

The parameter name review however is still very much work in progress:
https://github.com/php/php-tasks/issues/23 This is going slower than
anticipated, in part because parameter names are prime bikeshedding
material, so it can take a while to reach consensus.

In the last thread, Dmitry mentioned that he wanted to merge the JIT and VM
helpers. I don't believe that has happened, but also don't know what the
plans there are.

Regarding the branch cut, I think we can either:
1. Cut the branch tomorrow, freeze ABI and release RC1, but continue with
the parameter name review afterwards.
2. Delay RC1 again.

I'd probably go for 2. to avoid the extra merges for another two weeks --
as you said, activity targeting 8.0 is still rather high.

Regards,
Nikita

[PHP-DEV] PHP 8.0 branch cut - The Return

[Gabriel Caruso]

Following Sara's email a couple of weeks ago, I come this week with a
similar one:

Next Tuesday, Sep 29th, has been marked on our calendars as the branch date
for PHP-8.0 which would open master up for 8.1 targeted work.

This would mean that bug fixes would need to include PHP-8.0 in their merge
chain (meaning more work to merge 8.0 targeted fixes).

Please let Sara and I know how you feel about this date. We can see that
master is still quite active, especially with
https://github.com/php/php-tasks/issues/18 and
https://github.com/php/php-tasks/issues/16, and we don't wish to make the
work to stabilize
the 8.0 release any more difficult than it has to be.

Thanks,

Re: [PHP-DEV] PHP 8.0 branch cut

[Christoph M. Becker]

On 15.09.2020 at 09:29, Sebastian Bergmann wrote:

> Am 15.09.2020 um 09:24 schrieb Benjamin Eberlei:
>> The options to talk about and use in docs/posts are the following:
>>
>> opcache.jit=yes|true|1
>> opcache.jit=tracing
>> opcache.jit=function
>>
>> These differentiate the Tracing-JIT from the Function-JIT. Default is
>> tracing.
>
> Thanks!

See also .

--
Christoph M. Becker

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

Re: [PHP-DEV] PHP 8.0 branch cut

[Sebastian Bergmann]

Am 15.09.2020 um 09:24 schrieb Benjamin Eberlei:

The options to talk about and use in docs/posts are the following:

opcache.jit=yes|true|1
opcache.jit=tracing
opcache.jit=function

These differentiate the Tracing-JIT from the Function-JIT. Default is
tracing.


Thanks!

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

Re: [PHP-DEV] PHP 8.0 branch cut

[Benjamin Eberlei]

On Tue, Sep 15, 2020 at 8:20 AM Brent Roose  wrote:

> Hey Dmitiry
>
> Speaking of the JIT. I remember berblei mentioning that the JIT
> configuration options were going to change prior to the final 8 release (
> https://www.reddit.com/r/PHP/comments/hjxlh9/jit_benchmarks_on_reallife_web_applications/fwuje8g/
> <
> https://www.reddit.com/r/PHP/comments/hjxlh9/jit_benchmarks_on_reallife_web_applications/fwuje8g/>).
> In other words: not one value with several integer flags, but dedicated
> options for every configuration entry. Is this still on the roadmap?
>

 Hi Brent, Hi Sebastian,

this is already done by this PR https://github.com/php/php-src/pull/5913

The options to talk about and use in docs/posts are the following:

opcache.jit=yes|true|1
opcache.jit=tracing
opcache.jit=function

These differentiate the Tracing-JIT from the Function-JIT. Default is
tracing.

>
> Kind regards
> Brent
>
> > On 15 Sep 2020, at 07:05, Dmitry Stogov  wrote:
> >
> > This also gives me a time frame to clean up JIT code without hurry.
> > I plan to separate the common JIT code, and merge JIT and VM helpers.
> >
> > Thanks. Dmitry.
> >
> > On Mon, Sep 14, 2020 at 5:55 PM Sara Golemon  wrote:
> >
> >> On Mon, Sep 14, 2020 at 9:39 AM Nikita Popov 
> wrote:
> >>
> >>> On Fri, Sep 11, 2020 at 6:49 PM Sara Golemon  wrote:
> >>>
>  Next Tuesday, Sep 15th, has been marked on my calendar as the branch
> >> date
>  for PHP-8.0 which would open master up for 8.1 targeted work.
> 
>  This would mean that bug fixes would need to include PHP-8.0 in their
>  merge
>  chain (meaning more work to merge 8.0 targeted fixes).
> 
>  Please let Gabriel and I know how you feel about this date.  I can see
>  that
>  master is still quite active, and I don't wish to make the work to
>  stablize
>  the 8.0 release any more difficult than it has to be.
> 
> 
> >>>
> >>> I think it would be good to make this week's release beta4 rather than
> >> rc1
> >>> (without affecting the rest of the schedule). In that case we'd also
> push
> >>> back the branching and final ABI freeze two weeks.
> >>>
> >>> We're close to done with the warning to Error exception promotion task,
> >>> but haven't really started on reviewing and consolidating parameter
> names
> >>> yet (in preparation for named parameters). It would be good to have
> that
> >>> work mostly finalized before RC1, so we can limit the number of
> nominally
> >>> BC-breaking changes past RC1 (I expect we'll still fix some things that
> >>> slipped through the cracks, but at least we should prevent any mass
> >>> changes).
> >>>
> >>>
> >> Yep. This seems like a reasonable adjustment to the schedule in order to
> >> finalize these features.  I'll do beta4 tomorrow/thursday, and we should
> >> plan for RC1 branching in two weeks.  Wiki (
> >> https://wiki.php.net/todo/php80 )
> >> has been updated to reflect this.  Note that I have NOT moved the GA
> date
> >> at this time, as that would push us into Dec 10th.  Though as the date
> >> approaches we may decide to add RC5 back in for safety despite the
> >> perinavidinal timing.
> >>
> >> -Sara
> >>
> >> P.S. Yes, I made that word up. You know which one.
> >>
>
>

Re: [PHP-DEV] PHP 8.0 branch cut

[Brent Roose]

Hey Dmitiry

Speaking of the JIT. I remember berblei mentioning that the JIT configuration 
options were going to change prior to the final 8 release 
(https://www.reddit.com/r/PHP/comments/hjxlh9/jit_benchmarks_on_reallife_web_applications/fwuje8g/
 
).
 In other words: not one value with several integer flags, but dedicated 
options for every configuration entry. Is this still on the roadmap?

Kind regards
Brent

> On 15 Sep 2020, at 07:05, Dmitry Stogov  wrote:
> 
> This also gives me a time frame to clean up JIT code without hurry.
> I plan to separate the common JIT code, and merge JIT and VM helpers.
> 
> Thanks. Dmitry.
> 
> On Mon, Sep 14, 2020 at 5:55 PM Sara Golemon  wrote:
> 
>> On Mon, Sep 14, 2020 at 9:39 AM Nikita Popov  wrote:
>> 
>>> On Fri, Sep 11, 2020 at 6:49 PM Sara Golemon  wrote:
>>> 
 Next Tuesday, Sep 15th, has been marked on my calendar as the branch
>> date
 for PHP-8.0 which would open master up for 8.1 targeted work.
 
 This would mean that bug fixes would need to include PHP-8.0 in their
 merge
 chain (meaning more work to merge 8.0 targeted fixes).
 
 Please let Gabriel and I know how you feel about this date.  I can see
 that
 master is still quite active, and I don't wish to make the work to
 stablize
 the 8.0 release any more difficult than it has to be.
 
 
>>> 
>>> I think it would be good to make this week's release beta4 rather than
>> rc1
>>> (without affecting the rest of the schedule). In that case we'd also push
>>> back the branching and final ABI freeze two weeks.
>>> 
>>> We're close to done with the warning to Error exception promotion task,
>>> but haven't really started on reviewing and consolidating parameter names
>>> yet (in preparation for named parameters). It would be good to have that
>>> work mostly finalized before RC1, so we can limit the number of nominally
>>> BC-breaking changes past RC1 (I expect we'll still fix some things that
>>> slipped through the cracks, but at least we should prevent any mass
>>> changes).
>>> 
>>> 
>> Yep. This seems like a reasonable adjustment to the schedule in order to
>> finalize these features.  I'll do beta4 tomorrow/thursday, and we should
>> plan for RC1 branching in two weeks.  Wiki (
>> https://wiki.php.net/todo/php80 )
>> has been updated to reflect this.  Note that I have NOT moved the GA date
>> at this time, as that would push us into Dec 10th.  Though as the date
>> approaches we may decide to add RC5 back in for safety despite the
>> perinavidinal timing.
>> 
>> -Sara
>> 
>> P.S. Yes, I made that word up. You know which one.
>> 

Re: [PHP-DEV] PHP 8.0 branch cut

[Sebastian Bergmann]

Am 15.09.2020 um 08:19 schrieb Brent Roose:

Is this still on the roadmap?


I hope so, too.

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

Re: [PHP-DEV] PHP 8.0 branch cut

[Dmitry Stogov]

This also gives me a time frame to clean up JIT code without hurry.
I plan to separate the common JIT code, and merge JIT and VM helpers.

Thanks. Dmitry.

On Mon, Sep 14, 2020 at 5:55 PM Sara Golemon  wrote:

> On Mon, Sep 14, 2020 at 9:39 AM Nikita Popov  wrote:
>
> > On Fri, Sep 11, 2020 at 6:49 PM Sara Golemon  wrote:
> >
> >> Next Tuesday, Sep 15th, has been marked on my calendar as the branch
> date
> >> for PHP-8.0 which would open master up for 8.1 targeted work.
> >>
> >> This would mean that bug fixes would need to include PHP-8.0 in their
> >> merge
> >> chain (meaning more work to merge 8.0 targeted fixes).
> >>
> >> Please let Gabriel and I know how you feel about this date.  I can see
> >> that
> >> master is still quite active, and I don't wish to make the work to
> >> stablize
> >> the 8.0 release any more difficult than it has to be.
> >>
> >>
> >
> > I think it would be good to make this week's release beta4 rather than
> rc1
> > (without affecting the rest of the schedule). In that case we'd also push
> > back the branching and final ABI freeze two weeks.
> >
> > We're close to done with the warning to Error exception promotion task,
> > but haven't really started on reviewing and consolidating parameter names
> > yet (in preparation for named parameters). It would be good to have that
> > work mostly finalized before RC1, so we can limit the number of nominally
> > BC-breaking changes past RC1 (I expect we'll still fix some things that
> > slipped through the cracks, but at least we should prevent any mass
> > changes).
> >
> >
> Yep. This seems like a reasonable adjustment to the schedule in order to
> finalize these features.  I'll do beta4 tomorrow/thursday, and we should
> plan for RC1 branching in two weeks.  Wiki (
> https://wiki.php.net/todo/php80 )
> has been updated to reflect this.  Note that I have NOT moved the GA date
> at this time, as that would push us into Dec 10th.  Though as the date
> approaches we may decide to add RC5 back in for safety despite the
> perinavidinal timing.
>
> -Sara
>
> P.S. Yes, I made that word up. You know which one.
>

Re: [PHP-DEV] PHP 8.0 branch cut

[Sara Golemon]

On Mon, Sep 14, 2020 at 9:39 AM Nikita Popov  wrote:

> On Fri, Sep 11, 2020 at 6:49 PM Sara Golemon  wrote:
>
>> Next Tuesday, Sep 15th, has been marked on my calendar as the branch date
>> for PHP-8.0 which would open master up for 8.1 targeted work.
>>
>> This would mean that bug fixes would need to include PHP-8.0 in their
>> merge
>> chain (meaning more work to merge 8.0 targeted fixes).
>>
>> Please let Gabriel and I know how you feel about this date.  I can see
>> that
>> master is still quite active, and I don't wish to make the work to
>> stablize
>> the 8.0 release any more difficult than it has to be.
>>
>>
>
> I think it would be good to make this week's release beta4 rather than rc1
> (without affecting the rest of the schedule). In that case we'd also push
> back the branching and final ABI freeze two weeks.
>
> We're close to done with the warning to Error exception promotion task,
> but haven't really started on reviewing and consolidating parameter names
> yet (in preparation for named parameters). It would be good to have that
> work mostly finalized before RC1, so we can limit the number of nominally
> BC-breaking changes past RC1 (I expect we'll still fix some things that
> slipped through the cracks, but at least we should prevent any mass
> changes).
>
>
Yep. This seems like a reasonable adjustment to the schedule in order to
finalize these features.  I'll do beta4 tomorrow/thursday, and we should
plan for RC1 branching in two weeks.  Wiki ( https://wiki.php.net/todo/php80 )
has been updated to reflect this.  Note that I have NOT moved the GA date
at this time, as that would push us into Dec 10th.  Though as the date
approaches we may decide to add RC5 back in for safety despite the
perinavidinal timing.

-Sara

P.S. Yes, I made that word up. You know which one.

Re: [PHP-DEV] PHP 8.0 branch cut

[Nikita Popov]

On Fri, Sep 11, 2020 at 6:49 PM Sara Golemon  wrote:

> Next Tuesday, Sep 15th, has been marked on my calendar as the branch date
> for PHP-8.0 which would open master up for 8.1 targeted work.
>
> This would mean that bug fixes would need to include PHP-8.0 in their merge
> chain (meaning more work to merge 8.0 targeted fixes).
>
> Please let Gabriel and I know how you feel about this date.  I can see that
> master is still quite active, and I don't wish to make the work to stablize
> the 8.0 release any more difficult than it has to be.
>
> -Sara
>

Hey Sara,

I think it would be good to make this week's release beta4 rather than rc1
(without affecting the rest of the schedule). In that case we'd also push
back the branching and final ABI freeze two weeks.

We're close to done with the warning to Error exception promotion task, but
haven't really started on reviewing and consolidating parameter names yet
(in preparation for named parameters). It would be good to have that work
mostly finalized before RC1, so we can limit the number of nominally
BC-breaking changes past RC1 (I expect we'll still fix some things that
slipped through the cracks, but at least we should prevent any mass
changes).

Regards,
Nikita

[PHP-DEV] PHP 8.0 branch cut

[Sara Golemon]

Next Tuesday, Sep 15th, has been marked on my calendar as the branch date
for PHP-8.0 which would open master up for 8.1 targeted work.

This would mean that bug fixes would need to include PHP-8.0 in their merge
chain (meaning more work to merge 8.0 targeted fixes).

Please let Gabriel and I know how you feel about this date.  I can see that
master is still quite active, and I don't wish to make the work to stablize
the 8.0 release any more difficult than it has to be.

-Sara