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
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
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
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
Hi Nikita,
-----Original Message-----
From: Nikita Popov [mailto:nikita.ppv@gmail.com]
Sent: Thursday, April 20, 2017 7:06 PM
To: Sara Golemon pollita@php.net
Cc: PHP internals internals@lists.php.net
Subject: Re: [PHP-DEV] [7.2] TimetableMy 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
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
Hi Nikita,
-----Original Message-----
From: Nikita Popov [mailto:nikita.ppv@gmail.com]
Sent: Thursday, April 20, 2017 7:06 PM
To: Sara Golemon pollita@php.net
Cc: PHP internals internals@lists.php.net
Subject: Re: [PHP-DEV] [7.2] TimetableMy 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
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 RCIn 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
-----Original Message-----
From: Nikita Popov [mailto:nikita.ppv@gmail.com]
Sent: Saturday, April 22, 2017 1:49 PM
To: Anatol Belski ab@php.net
Cc: Sara Golemon pollita@php.net; PHP internals internals@lists.php.net
Subject: Re: [PHP-DEV] [7.2] TimetableTo 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
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
-----Original Message-----
From: Nikita Popov [mailto:nikita.ppv@gmail.com]
Sent: Saturday, April 22, 2017 1:49 PM
To: Anatol Belski ab@php.net
Cc: Sara Golemon pollita@php.net; PHP internals <
internals@lists.php.net>
Subject: Re: [PHP-DEV] [7.2] TimetableTo 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
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
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
Snooze Alarm: PHP-7.2 feature freeze is now TWO MONTHS away.
-Sara
I suggest to implement ??= for primitive types. Please discuss.
Thanks.
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
Snooze Alarm: PHP-7.2 feature freeze is now TWO MONTHS away.
-Sara
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]
Actually, it had an RFC and was accepted. It's just waiting for an
implementation that's not buggy.
-Sara
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]
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]