Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121650
MIME-Version: 1.0
References: <CAEKnhAHs-8aQwy89=xwgiLZzn=d8DKid9-S4m95jkNzxO0hARQ@mail.gmail.com>
 <CAPyj-LA278v4mEL3+BmxUUBgk5dW6x=Dssy-4RwWzAe0X4mqqQ@mail.gmail.com>
In-Reply-To: <CAPyj-LA278v4mEL3+BmxUUBgk5dW6x=Dssy-4RwWzAe0X4mqqQ@mail.gmail.com>
Date: Fri, 10 Nov 2023 20:22:27 +0000
Message-ID: <CAEKnhAGShvTi3UPqvw07Kkf2VP8c4YgNJ9Pj9GUR2QbUVhqrag@mail.gmail.com>
To: Ilija Tovilo <tovilo.ilija@gmail.com>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e58e690609d21474"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Release cycle update
From: bukka@php.net (Jakub Zelenka)

--000000000000e58e690609d21474
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Fri, Nov 10, 2023 at 5:56=E2=80=AFPM Ilija Tovilo <tovilo.ilija@gmail.co=
m> wrote:

> Hi Jakub
>
> Thank you for the proposal.
>
> On Fri, Nov 10, 2023 at 5:52=E2=80=AFPM Jakub Zelenka <bukka@php.net> wro=
te:
> > 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 c=
an
> 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 A=
BI
> 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

--000000000000e58e690609d21474--