Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121652
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-1108-g3a29173c6d-fm-20231031.005-g3a29173c
MIME-Version: 1.0
Message-ID: <f211900e-f7fd-4105-a161-08fdb86fd2b6@app.fastmail.com>
In-Reply-To: 
 <CAEKnhAGhBX8_tSnhvb4W3mUUWgCZE0jv72oQGxeNUgTgrP6FcA@mail.gmail.com>
References: 
 <CAEKnhAHs-8aQwy89=xwgiLZzn=d8DKid9-S4m95jkNzxO0hARQ@mail.gmail.com>
 <d6f35e18-2cbd-4ffe-b3dc-84c0c362da98@app.fastmail.com>
 <CAEKnhAGhBX8_tSnhvb4W3mUUWgCZE0jv72oQGxeNUgTgrP6FcA@mail.gmail.com>
Date: Fri, 10 Nov 2023 15:06:15 -0600
To: "php internals" <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: larry@garfieldtech.com ("Larry Garfield")

On Fri, Nov 10, 2023, at 2:11 PM, Jakub Zelenka wrote:
> Hi,
>
> On Fri, Nov 10, 2023 at 5:20=E2=80=AFPM Larry Garfield <larry@garfield=
tech.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=
 about
>> refactoring, bug fixes, edge case handling, etc.  Those are certainly
>> beta-friendly tasks, I agree, but I wouldn't describe those as "featu=
res."
>> The open hole here is that the description also talks about "minor fe=
atures
>> that don't require an RFC", the threshold for which is... highly flui=
d.
>> 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 cha=
nge
> 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=
 RFCs
>> are allowed).  Personally I would favor the latter, but as written th=
e text
>> is unclear on which is intended.
>>
>
> The proposal is to not introduce any extra alphas or betas and just sh=
orten
> 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 m=
y 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.

I suppose more to the point, does this mean the deadline for RFCs pushes=
 later?  That seems to be implied, but should be made explicit.

--Larry Garfield