Re: [RFC] [Discussion] Release cycle update
| From: | Larry Garfield | Date: | Fri, 10 Nov 2023 17:19:52 +0000 |
| Subject: | Re: [RFC] [Discussion] Release cycle update | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-121645@lists.php.net to get a copy of this message | ||
On Fri, Nov 10, 2023, at 10:51 AM, Jakub Zelenka wrote:
> 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