Hi,

On Fri, Nov 10, 2023 at 5:20 PM Larry Garfield <la...@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 about
> 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 features
> 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 RFCs
> are allowed).  Personally I would favor the latter, but as written the text
> 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

Reply via email to