Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121646
MIME-Version: 1.0
References: <CAEKnhAHs-8aQwy89=xwgiLZzn=d8DKid9-S4m95jkNzxO0hARQ@mail.gmail.com>
In-Reply-To: <CAEKnhAHs-8aQwy89=xwgiLZzn=d8DKid9-S4m95jkNzxO0hARQ@mail.gmail.com>
Date: Fri, 10 Nov 2023 18:55:43 +0100
Message-ID: <CAPyj-LA278v4mEL3+BmxUUBgk5dW6x=Dssy-4RwWzAe0X4mqqQ@mail.gmail.com>
To: PHP internals list <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] [Discussion] Release cycle update
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Jakub

Thank you for the proposal.

On Fri, Nov 10, 2023 at 5:52=E2=80=AFPM Jakub Zelenka <bukka@php.net> wrote=
:
> https://wiki.php.net/rfc/release_cycle_update

> Currently beta is called a feature freeze but effectively it isn't. The m=
ain issue with that is that the end of alpha just means that all RFC's targ=
eting that version must have voting finished but the implementation can be =
done during beta. This is however a major inconsistency because RFC impleme=
ntations are often those that can have a major impact on API and ABI stabil=
ity 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