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,
On Mon, Sep 28, 2020 at 10:56 AM Gabriel Caruso carusogabriel@php.net
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:
- Cut the branch tomorrow, freeze ABI and release RC1, but continue with
the parameter name review afterwards. - 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
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 carusogabriel@php.net
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,
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é
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
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 timeI 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
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 timeI 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.
On Tue, Sep 29, 2020 at 5:00 PM Gabriel Caruso carusogabriel@php.net
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
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
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--
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
On Mon, Sep 28, 2020 at 10:56 AM Gabriel Caruso carusogabriel@php.net
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
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