Hello,
I would like to propose a new process RFC for updates to PHP release cycle:
https://wiki.php.net/rfc/release_cycle_update
This has been discussed between release managers to make sure that all are
happy as some of the points impact release managers (e.g. longer security
support).
I also opened a PR to my new personal repo for RFC's if anyone has got any
suggestion for better wording or notices any typo:
https://github.com/bukka/php-rfc/pull/1
Cheers
Jakub
Hello,
I would like to propose a new process RFC for updates to PHP release cycle:
https://wiki.php.net/rfc/release_cycle_update
This has been discussed between release managers to make sure that all are
happy as some of the points impact release managers (e.g. longer security
support).I also opened a PR to my new personal repo for RFC's if anyone has got any
suggestion for better wording or notices any typo:https://github.com/bukka/php-rfc/pull/1
Cheers
Jakub
If the release managers are in favor, I am in favor, generally. I'm sure the longer security cycle will get cheers from hosting organizations and jeers from package maintainers. :-)
A few questions/comments/observations:
-
"Allow feature that do not require RFC in beta" - The description doesn't quite sound like it's talking about "features." It's talking about refactoring, bug fixes, edge case handling, etc. Those are certainly beta-friendly tasks, I agree, but I wouldn't describe those as "features." The open hole here is that the description also talks about "minor features that don't require an RFC", the threshold for which is... highly fluid. That's a potential confusion point.
-
Reduce number of RC to 4 - I support this! However, it's not clear if that means we get an extra 2 betas, or an extra month of alpha (where RFCs are allowed). Personally I would favor the latter, but as written the text is unclear on which is intended.
Including a revised calendar of what happens when under this policy in a table or chart or something would be very helpful.
--Larry Garfield
Hi,
On Fri, Nov 10, 2023 at 5:20 PM Larry Garfield larry@garfieldtech.com
wrote:
- "Allow feature that do not require RFC in beta" - The description
doesn't quite sound like it's talking about "features." It's talking about
refactoring, bug fixes, edge case handling, etc. Those are certainly
beta-friendly tasks, I agree, but I wouldn't describe those as "features."
The open hole here is that the description also talks about "minor features
that don't require an RFC", the threshold for which is... highly fluid.
That's a potential confusion point.
So there are actually many small features (adding constant, parameters,
config options or even small functions / methods) that are being merged
without RFC to master. In general if there are no objections, such change
is merged. So effectively the proposal is to keep doing that in beta as
well because some bigger features (approved RFCs) can be merged too.
- Reduce number of RC to 4 - I support this! However, it's not clear if
that means we get an extra 2 betas, or an extra month of alpha (where RFCs
are allowed). Personally I would favor the latter, but as written the text
is unclear on which is intended.
The proposal is to not introduce any extra alphas or betas and just shorten
the whole pre-release time. Effectively alpha does not have almost any
meaning rather than just announcement and probably more importantly a test
for new RM's how to do a release (that's actually pretty useful from my own
experience) so there is no point to do more than 3 alphas. And beta is
currently more just time to get the RFC implemented but there is
effectively no real feature freeze - ABI is still open for changes and RFC
can be merged as I mentioned above. So not sure if there's much point to
have more than 3.
The text needs probably clarifying so I will update it.
Thanks
Jakub
Hi,
On Fri, Nov 10, 2023 at 5:20 PM Larry Garfield larry@garfieldtech.com
wrote:
- "Allow feature that do not require RFC in beta" - The description
doesn't quite sound like it's talking about "features." It's talking about
refactoring, bug fixes, edge case handling, etc. Those are certainly
beta-friendly tasks, I agree, but I wouldn't describe those as "features."
The open hole here is that the description also talks about "minor features
that don't require an RFC", the threshold for which is... highly fluid.
That's a potential confusion point.So there are actually many small features (adding constant, parameters,
config options or even small functions / methods) that are being merged
without RFC to master. In general if there are no objections, such change
is merged. So effectively the proposal is to keep doing that in beta as
well because some bigger features (approved RFCs) can be merged too.
- Reduce number of RC to 4 - I support this! However, it's not clear if
that means we get an extra 2 betas, or an extra month of alpha (where RFCs
are allowed). Personally I would favor the latter, but as written the text
is unclear on which is intended.The proposal is to not introduce any extra alphas or betas and just shorten
the whole pre-release time. Effectively alpha does not have almost any
meaning rather than just announcement and probably more importantly a test
for new RM's how to do a release (that's actually pretty useful from my own
experience) so there is no point to do more than 3 alphas. And beta is
currently more just time to get the RFC implemented but there is
effectively no real feature freeze - ABI is still open for changes and RFC
can be merged as I mentioned above. So not sure if there's much point to
have more than 3.The text needs probably clarifying so I will update it.
I suppose more to the point, does this mean the deadline for RFCs pushes later? That seems to be implied, but should be made explicit.
--Larry Garfield
Hi Jakub
Thank you for the proposal.
Currently beta is called a feature freeze but effectively it isn't. The main issue with that is that the end of alpha just means that all RFC's targeting that version must have voting finished but the implementation can be done during beta. This is however a major inconsistency because RFC implementations are often those that can have a major impact on API and ABI stability so it seems illogical to allow that but don't allow minor improvements that do not require RFC.
I think the general expectation with the current process is that an
RFC implementation would be merged reasonably shortly after feature
freeze. Extending this to the entire beta period may be risky,
especially if we're also shortening the RC period. With an
implementation merged last-minute, this gives us 2 months to iron out
any issues. With multiple RFCs merged last-minute things could become
quite overwhelming.
I also think library maintainers might want more than 2 months time to
make and test their changes, especially when it comes to BC
incompatible changes.
I'm not sure how this can be addressed. We should at least encourage
changes to be merged early in the beta cycle.
Ilija
Hi,
Hi Jakub
Thank you for the proposal.
Currently beta is called a feature freeze but effectively it isn't. The
main issue with that is that the end of alpha just means that all RFC's
targeting that version must have voting finished but the implementation can
be done during beta. This is however a major inconsistency because RFC
implementations are often those that can have a major impact on API and ABI
stability so it seems illogical to allow that but don't allow minor
improvements that do not require RFC.I think the general expectation with the current process is that an
RFC implementation would be merged reasonably shortly after feature
freeze. Extending this to the entire beta period may be risky,
especially if we're also shortening the RC period. With an
implementation merged last-minute, this gives us 2 months to iron out
any issues. With multiple RFCs merged last-minute things could become
quite overwhelming.
I think there should be a clear cut when the RFC can be implemented and
there should be probably still time to apply ABI breaking changes after
that time. So we could potentially decrease the time for the RFC
implementation needs to be merged. Maybe something like this:
- 2 alphas - think 2 are enough as each RM can try one release.
- 4 betas and require that all RFC has to be merged before beta3 is
released. It means we would have 2 extra betas to iron out all RFC issues
and still be able to introduce ABI breaks - 4 RC - real feature freeze without any ABI or API breaks
What do you think?
Cheers
Jakub
Hi
- 2 alphas - think 2 are enough as each RM can try one release.
- 4 betas and require that all RFC has to be merged before beta3 is
released. It means we would have 2 extra betas to iron out all RFC issues
and still be able to introduce ABI breaks
Should this read: "before beta 3 is tagged"? An RFC could be merged
after the tag and before the release, and then there would only one
remaining Beta for it.
- 4 RC - real feature freeze without any ABI or API breaks
Best regards
Tim Düsterhus
Hi,
I think there should be a clear cut when the RFC can be implemented and
there should be probably still time to apply ABI breaking changes after
that time. So we could potentially decrease the time for the RFC
implementation needs to be merged. Maybe something like this:
- 2 alphas - think 2 are enough as each RM can try one release.
- 4 betas and require that all RFC has to be merged before beta3 is
released. It means we would have 2 extra betas to iron out all RFC issues
and still be able to introduce ABI breaks- 4 RC - real feature freeze without any ABI or API breaks
What do you think?
I think that makes sense.
cheers
Derick
Hello,
I would like to propose a new process RFC for updates to PHP release cycle:
Hi,
I started writing a suggestion that you add details to your RFC of what text we would remove or change in the existing policy if approved - what you've presented so far is like a good commit message, but we probably want a diff to go with it.
However, looking at the existing "policy", most of the things you want to change aren't actually in it - it doesn't even contain the word "beta". It also has parts that are obviously outdated ("Features can use branch(es) if necessary" - because the project was using SVN, where branches are costly to maintain), parts in the future tense, and even open questions (about who can vote for RMs).
So maybe what's really needed is to draft a new copy of the policy document, updating or removing those parts that are no longer relevant, and adding a timeline for the pre-release phases?
Or possibly there's a different document I should be looking at, and the RFC could contain proposed edits to that?
Regards,
--
Rowan Tommins
[IMSoP]
2023年11月11日(土) 8:27 Rowan Tommins rowan.collins@gmail.com:
Hello,
I would like to propose a new process RFC for updates to PHP release cycle:
Hi,
I started writing a suggestion that you add details to your RFC of what text we would remove or change in the existing policy if approved - what you've presented so far is like a good commit message, but we probably want a diff to go with it.
However, looking at the existing "policy", most of the things you want to change aren't actually in it - it doesn't even contain the word "beta". It also has parts that are obviously outdated ("Features can use branch(es) if necessary" - because the project was using SVN, where branches are costly to maintain), parts in the future tense, and even open questions (about who can vote for RMs).
So maybe what's really needed is to draft a new copy of the policy document, updating or removing those parts that are no longer relevant, and adding a timeline for the pre-release phases?
Or possibly there's a different document I should be looking at, and the RFC could contain proposed edits to that?
Regards,
--
Rowan Tommins
[IMSoP]--
To unsubscribe, visit: https://www.php.net/unsub.php
Hi, Internals
From mbstring point of view, PHP 8.0 is last version of not affected
"Major overhaul of mbstring".
For example, PHP 8.0's mb_detect_encoding not affected to below.
If PHP 8.0's EOL is one more year, There is a one-year grace period
for upgrades.
Regards
Yuya
--
Yuya Hamada (tekimen)
Hello,
I would like to propose a new process RFC for updates to PHP release cycle:
Hi,
I started writing a suggestion that you add details to your RFC of what text we would remove or change in the existing policy if approved - what you've presented so far is like a good commit message, but we probably want a diff to go with it.
However, looking at the existing "policy", most of the things you want to change aren't actually in it - it doesn't even contain the word "beta". It also has parts that are obviously outdated ("Features can use branch(es) if necessary" - because the project was using SVN, where branches are costly to maintain), parts in the future tense, and even open questions (about who can vote for RMs).
So maybe what's really needed is to draft a new copy of the policy document, updating or removing those parts that are no longer relevant, and adding a timeline for the pre-release phases?
Or possibly there's a different document I should be looking at, and the RFC could contain proposed edits to that?
Regards,
I already have been collecting most of the policy things together in one document:
https://docs.google.com/document/d/1Wc84ZxHHamvWsZl-U2kFOrbJDEXyXFv1laePN4ijJGQ/edit?usp=drivesdk
For the same reasons really. The info was spread out a lot.
cheers
Derick
Le 10/11/2023 à 17:51, Jakub Zelenka a écrit :
Hello,
I would like to propose a new process RFC for updates to PHP release cycle:
Extending security support by one year
+1
Allowing recent regression fixes during security support
As regression are often discovered quickly, 12 months is perhaps too
much. BTW, such fix will need RM approval, so
+1
Disallowing new features completely in RC and bug fixing release
+1
With RM exception
Allow feature that do not require RFC in beta
+1
With RM approval
Reduce number of RC to 4
Yes pre-release cycle is long
But RC time is used by other project for test/fix
especially for pecl extension to fix compatibility
IMHO 4 months seems fine for minor version (e.g. 8.4)
but not enough for major version (e.g. 9.0)
The changes will apply immediately on the all currently supported
branches from PHP-8.1.
It means that PHP-8.0 would get an extra year of security fixes if
that proposal is accepted.
Hmm... this sentence is ambiguous ;)
Should be 8.1 for both, right ?
Remi
Hello,
I would like to propose a new process RFC for updates to PHP release cycle:
https://wiki.php.net/rfc/release_cycle_update
This has been discussed between release managers to make sure that all are
happy as some of the points impact release managers (e.g. longer security
support).I also opened a PR to my new personal repo for RFC's if anyone has got any
suggestion for better wording or notices any typo:
Thank you Jakub for putting this together. A lot of this makes sense to
me, but the shortening of the feature freeze period from effectively 18
weeks (with some exceptions) to 8 weeks concerns me.
While this is not a concern for applications in a controlled
environment, this is a concern for open source projects which don't have
control over the environment the software is being run on and therefore
generally "have to be" (try to be) deprecation-free "early", especially
packages which are used in the CI/QA chain of open source applications
(think: Composer, PHPUnit, Mockery, Pest etc) and frameworks which are
widely extended, where the extensions can't really verify their own
readiness until the framework is deprecation-free (think: WordPress and
its plugin system).
Taking that into account, I would like suggest the following:
- Yes, 4 RCs, but instead of 2 weeks between each, have 3 weeks between
each. That way the RC period remains the same, allowing the open source
world to get ready in time, while still lessening the workload. - Regarding moving the feature freeze to the first RC: I can see the
benefits of small features still being allowed in, but deprecations
going in late is a different matter. While PHP 8.3 was "light" in
regards to the impact of deprecations, PHP 8.1 and 8.2 were a whole
different kettle of fish. With that in mind, I'd like to suggest
deprecations/removals to only be allowed in up to beta 1, with new RFC
features and other small changes being allowed in until RC1.
I hope you'll consider these suggestions.
Smile,
Juliette