Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] [7.2] Timetable

Posted by Sara Golemon 
Sara Golemon
[PHP-DEV] [7.2] Timetable
April 20, 2017 06:50PM
My how time flies! Feature Freeze for PHP-7.2 is coming up in exactly
THREE MONTHS on July 20th. Get your RFCs discussed, voted on, and
implemented unless you want to wait for PHP-7.3

-Sara

Ref: https://wiki.php.net/todo/php72#timetable

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Nikita Popov
Re: [PHP-DEV] [7.2] Timetable
April 20, 2017 07:10PM
On Thu, Apr 20, 2017 at 6:43 PM, Sara Golemon <[email protected]> wrote:

> My how time flies! Feature Freeze for PHP-7.2 is coming up in exactly
> THREE MONTHS on July 20th. Get your RFCs discussed, voted on, and
> implemented unless you want to wait for PHP-7.3
>
> -Sara
>
> Ref: https://wiki.php.net/todo/php72#timetable
>

I've been wondering for some time why we have the beta + RC split, where
RCs are treated in essentially the same way as betas. In particular our
minor version RCs (as opposed to patch RCs) are *not* candidates for
release. Might it make sense to move RC1-5 to Beta 4-9 and keep only one
scheduled RC?

Similarly, does it really make sense to have a new pre-release every two
weeks? I know that "we've always done it this way", but I'm not sure I see
the motivation behind it (or who the target audience for a biweekly release
is).

Nikita
Stanislav Malyshev
Re: [PHP-DEV] [7.2] Timetable
April 20, 2017 07:30PM
Hi!

> Similarly, does it really make sense to have a new pre-release every two
> weeks? I know that "we've always done it this way", but I'm not sure I see
> the motivation behind it (or who the target audience for a biweekly release
> is).

I'd leave it to the RM, if nothing substantial changes in two weeks,
there might not be a point of releasing essentially the same code. If,
OTOH, a major change lands, it may make sense to get it out ASAP.

The target would be the major frameworks and distros who might be
disrupted by the said major change, I guess...

I think difference between Beta and RC is mostly aesthetic, RC means "it
is really happening now, the train is departing!" :)
--
Stas Malyshev
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Anatol Belski
RE: [PHP-DEV] [7.2] Timetable
April 22, 2017 01:20PM
Hi Nikita,

> -----Original Message-----
> From: Nikita Popov [mailto:[email protected]]
> Sent: Thursday, April 20, 2017 7:06 PM
> To: Sara Golemon <[email protected]>
> Cc: PHP internals <[email protected]>
> Subject: Re: [PHP-DEV] [7.2] Timetable
>
> On Thu, Apr 20, 2017 at 6:43 PM, Sara Golemon <[email protected]> wrote:
>
> > My how time flies! Feature Freeze for PHP-7.2 is coming up in exactly
> > THREE MONTHS on July 20th. Get your RFCs discussed, voted on, and
> > implemented unless you want to wait for PHP-7.3
> >
> > -Sara
> >
> > Ref: https://wiki.php.net/todo/php72#timetable
> >
>
> I've been wondering for some time why we have the beta + RC split, where RCs
> are treated in essentially the same way as betas. In particular our minor version
> RCs (as opposed to patch RCs) are *not* candidates for release. Might it make
> sense to move RC1-5 to Beta 4-9 and keep only one scheduled RC?
>
Yeah, it's a bit unusual, as many projects usually have all the way alpha/beta and then one or max two RCs. On the other hand, a paradox fact is, that the QA participation on beta is far lower, at least from what I could tell from the past. Maybe that's just due to the naming, so people decide not to bother testing early stages and wait for something more substantial, I can only guess at here. On the other hand, nothing prevents RMs to switch back to beta, if there are some hard weight issues discovered, thus reflecting the dev state. Maybe there was some other reasons, why it was initially done this way, though.

> Similarly, does it really make sense to have a new pre-release every two weeks?
> I know that "we've always done it this way", but I'm not sure I see the
> motivation behind it (or who the target audience for a biweekly release is).
>
From my experience, it is a very helpful approach. A pre release in this case is a kind of a buffer we have, to ensure the previous development didn't cause follow up issues. It could be illustrated by this primitive time lines

---> development ----------------> patch X reverted ---------> further development
--------------> snapshot RC ------> patch X reverted in RC ----------> final based on RC

In many cases this approach helps to catch one or another issue, so it's not included into the final patch version.

Regarding the target audience, I can tell that the RCs are tested by Remi Collet on Fedora, by the OSTC team on Windows and some other third parties. It is useful also to ask some particular reporter to test the RC to ensure the exact fix will be contained in the GA release. Fe in some case, a buggy patch can still stay in the dev and be fixed, but excluded from the release and tested in the subsequent RC. In some case, there theoretically could be even RC2 for a patch version. I had never to do that, but basically that's an option if some very bad road blocks would appear in RC1. For the stability this approach is suitable quite well, as for me.

Regards

Anatol
Nikita Popov
Re: [PHP-DEV] [7.2] Timetable
April 22, 2017 02:00PM
On Sat, Apr 22, 2017 at 1:09 PM, Anatol Belski <[email protected]> wrote:

> Hi Nikita,
>
> > -----Original Message-----
> > From: Nikita Popov [mailto:[email protected]]
> > Sent: Thursday, April 20, 2017 7:06 PM
> > To: Sara Golemon <[email protected]>
> > Cc: PHP internals <[email protected]>
> > Subject: Re: [PHP-DEV] [7.2] Timetable
> >
> > On Thu, Apr 20, 2017 at 6:43 PM, Sara Golemon <[email protected]> wrote:
> >
> > > My how time flies! Feature Freeze for PHP-7.2 is coming up in exactly
> > > THREE MONTHS on July 20th. Get your RFCs discussed, voted on, and
> > > implemented unless you want to wait for PHP-7.3
> > >
> > > -Sara
> > >
> > > Ref: https://wiki.php.net/todo/php72#timetable
> > >
> >
> > I've been wondering for some time why we have the beta + RC split, where
> RCs
> > are treated in essentially the same way as betas. In particular our
> minor version
> > RCs (as opposed to patch RCs) are *not* candidates for release. Might it
> make
> > sense to move RC1-5 to Beta 4-9 and keep only one scheduled RC?
> >
> Yeah, it's a bit unusual, as many projects usually have all the way
> alpha/beta and then one or max two RCs. On the other hand, a paradox fact
> is, that the QA participation on beta is far lower, at least from what I
> could tell from the past. Maybe that's just due to the naming, so people
> decide not to bother testing early stages and wait for something more
> substantial, I can only guess at here. On the other hand, nothing prevents
> RMs to switch back to beta, if there are some hard weight issues
> discovered, thus reflecting the dev state. Maybe there was some other
> reasons, why it was initially done this way, though.
>
> > Similarly, does it really make sense to have a new pre-release every two
> weeks?
> > I know that "we've always done it this way", but I'm not sure I see the
> > motivation behind it (or who the target audience for a biweekly release
> is).
> >
> From my experience, it is a very helpful approach. A pre release in this
> case is a kind of a buffer we have, to ensure the previous development
> didn't cause follow up issues. It could be illustrated by this primitive
> time lines
>
> ---> development ----------------> patch X reverted ---------> further
> development
> --------------> snapshot RC ------> patch X reverted in RC ---------->
> final based on RC
>
> In many cases this approach helps to catch one or another issue, so it's
> not included into the final patch version.
>
> Regarding the target audience, I can tell that the RCs are tested by Remi
> Collet on Fedora, by the OSTC team on Windows and some other third parties.
> It is useful also to ask some particular reporter to test the RC to ensure
> the exact fix will be contained in the GA release. Fe in some case, a buggy
> patch can still stay in the dev and be fixed, but excluded from the release
> and tested in the subsequent RC. In some case, there theoretically could be
> even RC2 for a patch version. I had never to do that, but basically that's
> an option if some very bad road blocks would appear in RC1. For the
> stability this approach is suitable quite well, as for me.
>

To clarify, I wasn't referring to our patch release RCs here, I certainly
see the usefulness of those. What I had in mind is that the current release
timeline for PHP 7.2 plans one new release (alpha, beta or RC) *every two
weeks* starting June 8th and continuing for 12 releases. This seems
excessive and I don't think there are many people who are interested in
testing a new release every two weeks. At least after the alpha phase the
PHP-7.2 branch should be about as low-activity as our other release
branches (as all features have landed by this time), so there will not be a
lot of changes between releases two weeks apart. This fast-paced release
cycle is probably also part of the reason why we have to do the beta/RC
switch early, as it's pretty hard to take a "beta 9" seriously, it's just
"yet another beta" at that point.

I don't think we'd lose much (actually I suspect that reducing the number
of releases will increase willingness to test them) if we used a monthly
release cycle instead (e.g. using 2 alphas, 2 betas and 2 RCs.)

Nikita
Anatol Belski
RE: [PHP-DEV] [7.2] Timetable
April 22, 2017 11:10PM
> -----Original Message-----
> From: Nikita Popov [mailto:[email protected]]
> Sent: Saturday, April 22, 2017 1:49 PM
> To: Anatol Belski <[email protected]>
> Cc: Sara Golemon <[email protected]>; PHP internals <[email protected]>
> Subject: Re: [PHP-DEV] [7.2] Timetable
>
> To clarify, I wasn't referring to our patch release RCs here, I certainly see the
> usefulness of those. What I had in mind is that the current release timeline for
> PHP 7.2 plans one new release (alpha, beta or RC) *every two weeks* starting
> June 8th and continuing for 12 releases. This seems excessive and I don't think
> there are many people who are interested in testing a new release every two
> weeks. At least after the alpha phase the PHP-7.2 branch should be about as
> low-activity as our other release branches (as all features have landed by this
> time), so there will not be a lot of changes between releases two weeks apart.
> This fast-paced release cycle is probably also part of the reason why we have to
> do the beta/RC switch early, as it's pretty hard to take a "beta 9" seriously, it's
> just "yet another beta" at that point.
>
>
> I don't think we'd lose much (actually I suspect that reducing the number of
> releases will increase willingness to test them) if we used a monthly release
> cycle instead (e.g. using 2 alphas, 2 betas and 2 RCs.)
>
Ah, I understood it in wrong direction then. For the minor pre cycle, probably some release could be omitted, if there's no activity, like we currently do with a security branch. AFAIR there was no case like that with 7.0, but that's also clear why as it was a major change. Probably would be good to hear more impressions from RMs about how it went with other branches. The timeline is anyway just a planning, it could be good that some beta could replace the planned RC, if there are some issues. Depending on impressions others have, probably the process could be indeed slackened a bit, needing an RFC and extension to the release process doc. Maybe it could be enough to have a release monthly, or more frequent if some urgent fixes are to be tested, with the distance of two weeks as minimum.

Not the last factor here is, I can tell, is also that the new RMs have more practice on the actual release process. There are several nuances that are better to be practiced before it comes to GA.

Regards

Anatol
Davey Shafik
Re: [PHP-DEV] [7.2] Timetable
April 23, 2017 06:30AM
As I recall the 7.1.0 release process there was never a time when a
scheduled release didn't have enough changes to warrant it.

I think consistently scheduled releases give us a few things:

- Early access to changes as they progress
- Predictable timelines
- No rush to get a bunch of things in because the next one is only two
weeks away

Additionally, the value of the multiple RCs is that it gives a nice runway
between when breaking changes and new RFCs are allowed in and shoring up
implementations for the release. Ideally, you'd have more Alphas than
Betas, and more Betas and than RCs, but the reality is that until you
freeze for RC, the dust doesn't settle.

I think the current release schedule (or similar) has produced good
results, and see no reason to change it unless we change some of the
semantics. E.g. more Alphas, but no more RFCs after Beta 1, but you're just
shifting the process down the line a bit, it's just names at that point.

- Davey

On Sat, Apr 22, 2017 at 2:05 PM, Anatol Belski <[email protected]> wrote:

>
>
> > -----Original Message-----
> > From: Nikita Popov [mailto:[email protected]]
> > Sent: Saturday, April 22, 2017 1:49 PM
> > To: Anatol Belski <[email protected]>
> > Cc: Sara Golemon <[email protected]>; PHP internals <
> internals@lists.php.net>
> > Subject: Re: [PHP-DEV] [7.2] Timetable
> >
> > To clarify, I wasn't referring to our patch release RCs here, I
> certainly see the
> > usefulness of those. What I had in mind is that the current release
> timeline for
> > PHP 7.2 plans one new release (alpha, beta or RC) *every two weeks*
> starting
> > June 8th and continuing for 12 releases. This seems excessive and I
> don't think
> > there are many people who are interested in testing a new release every
> two
> > weeks. At least after the alpha phase the PHP-7.2 branch should be about
> as
> > low-activity as our other release branches (as all features have landed
> by this
> > time), so there will not be a lot of changes between releases two weeks
> apart.
> > This fast-paced release cycle is probably also part of the reason why we
> have to
> > do the beta/RC switch early, as it's pretty hard to take a "beta 9"
> seriously, it's
> > just "yet another beta" at that point.
> >
> >
> > I don't think we'd lose much (actually I suspect that reducing the
> number of
> > releases will increase willingness to test them) if we used a monthly
> release
> > cycle instead (e.g. using 2 alphas, 2 betas and 2 RCs.)
> >
> Ah, I understood it in wrong direction then. For the minor pre cycle,
> probably some release could be omitted, if there's no activity, like we
> currently do with a security branch. AFAIR there was no case like that with
> 7.0, but that's also clear why as it was a major change. Probably would be
> good to hear more impressions from RMs about how it went with other
> branches. The timeline is anyway just a planning, it could be good that
> some beta could replace the planned RC, if there are some issues. Depending
> on impressions others have, probably the process could be indeed slackened
> a bit, needing an RFC and extension to the release process doc. Maybe it
> could be enough to have a release monthly, or more frequent if some urgent
> fixes are to be tested, with the distance of two weeks as minimum.
>
> Not the last factor here is, I can tell, is also that the new RMs have
> more practice on the actual release process. There are several nuances that
> are better to be practiced before it comes to GA.
>
> Regards
>
> Anatol
>
Johannes Schlüter
Re: [PHP-DEV] [7.2] Timetable
April 24, 2017 02:00PM
On Do, 2017-04-20 at 19:06 +0200, Nikita Popov wrote:
> I've been wondering for some time why we have the beta + RC split,
> where RCs are treated in essentially the same way as betas. In
> particular our minor version RCs (as opposed to patch RCs) are *not*
> candidates for release. Might it make sense to move RC1-5 to Beta 4-9
> and keep only one scheduled RC?

In addition to what othhers said: RC gives an argument to the RM
"sorry, we're in RC, this is a too big change" but gives a chance to
catch and fix issues.

johannes


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sara Golemon
[PHP-DEV] Re: [7.2] Timetable
May 21, 2017 02:20AM
On Thu, Apr 20, 2017 at 11:43 AM, Sara Golemon <[email protected]> wrote:
> My how time flies! Feature Freeze for PHP-7.2 is coming up in exactly
> THREE MONTHS on July 20th. Get your RFCs discussed, voted on, and
> implemented unless you want to wait for PHP-7.3
>
> -Sara
>
> Ref: https://wiki.php.net/todo/php72#timetable
>
Snooze Alarm: PHP-7.2 feature freeze is now TWO MONTHS away.

-Sara

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Midori Koçak
Re: [PHP-DEV] [7.2] Timetable
May 21, 2017 12:40PM
I suggest to implement ??= for primitive types. Please discuss.

Thanks.

> On 21 May 2017, at 02:08, Sara Golemon <[email protected]> wrote:
>
> On Thu, Apr 20, 2017 at 11:43 AM, Sara Golemon <[email protected]> wrote:
>> My how time flies! Feature Freeze for PHP-7.2 is coming up in exactly
>> THREE MONTHS on July 20th. Get your RFCs discussed, voted on, and
>> implemented unless you want to wait for PHP-7.3
>>
>> -Sara
>>
>> Ref: https://wiki.php.net/todo/php72#timetable
>>
> Snooze Alarm: PHP-7.2 feature freeze is now TWO MONTHS away.
>
> -Sara
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
Attachments:
open | download - smime.p7s (1.6 KB)
Rowan Collins
Re: [PHP-DEV] [7.2] Timetable
May 21, 2017 06:30PM
On 21 May 2017 11:32:06 BST, "Midori Koçak" <[email protected]> wrote:
>I suggest to implement ??= for primitive types. Please discuss.

This sounds like it should be its own thread, with a lot more detail, leading eventually to an RFC https://wiki.php.net/rfc/howto

If you've already started a discussion somewhere, maybe post in that thread, or start a new one with a link to relevant archive, if you want more responses.

Regards,

--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sara Golemon
Re: [PHP-DEV] [7.2] Timetable
May 22, 2017 03:00AM
Actually, it had an RFC and was accepted. It's just waiting for an
implementation that's not buggy.

-Sara

On Sun, May 21, 2017 at 11:25 AM, Rowan Collins <[email protected]> wrote:
> On 21 May 2017 11:32:06 BST, "Midori Koçak" <[email protected]> wrote:
>>I suggest to implement ??= for primitive types. Please discuss.
>
> This sounds like it should be its own thread, with a lot more detail, leading eventually to an RFC https://wiki.php.net/rfc/howto
>
> If you've already started a discussion somewhere, maybe post in that thread, or start a new one with a link to relevant archive, if you want more responses.
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Rowan Collins
Re: [PHP-DEV] [7.2] Timetable
May 22, 2017 09:20AM
On 22/05/2017 01:58, Sara Golemon wrote:
> Actually, it had an RFC and was accepted. It's just waiting for an
> implementation that's not buggy.

Ah, beg its pardon, I looked for it in the wrong place. I apologise for
jumping to the wrong conclusion.

Regards,

--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, only registered users may post in this forum.

Click here to login