Hi, On Fri, Nov 10, 2023 at 5:56 PM Ilija Tovilo <tovilo.il...@gmail.com> wrote:
> Hi Jakub > > Thank you for the proposal. > > On Fri, Nov 10, 2023 at 5:52 PM Jakub Zelenka <bu...@php.net> wrote: > > https://wiki.php.net/rfc/release_cycle_update > > > 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
