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