Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121649
MIME-Version: 1.0
References: <CAEKnhAHs-8aQwy89=xwgiLZzn=d8DKid9-S4m95jkNzxO0hARQ@mail.gmail.com>
 <d6f35e18-2cbd-4ffe-b3dc-84c0c362da98@app.fastmail.com>
In-Reply-To: <d6f35e18-2cbd-4ffe-b3dc-84c0c362da98@app.fastmail.com>
Date: Fri, 10 Nov 2023 20:11:00 +0000
Message-ID: <CAEKnhAGhBX8_tSnhvb4W3mUUWgCZE0jv72oQGxeNUgTgrP6FcA@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f1dde50609d1ebaa"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Release cycle update
From: bukka@php.net (Jakub Zelenka)

--000000000000f1dde50609d1ebaa
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Fri, Nov 10, 2023 at 5:20=E2=80=AFPM 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 abo=
ut
> 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 featur=
es
> 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 RFC=
s
> are allowed).  Personally I would favor the latter, but as written the te=
xt
> 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

--000000000000f1dde50609d1ebaa--