Good question. CC-ed the release managers. My 2-cents: I think the purpose of feature freeze is to prevent new feature / improvement changes from destabilizing the code base, in order to get a stable and verified release. Based on this, I'd suggest: - Considering FLIPs that purely mark an API as deprecated and do not introduce anything new as "not a new feature", because that can hardly cause any trouble. - Considering FLIPs that introduce new / replacing APIs in addition to deprecating old ones as "new features or improvements". Merging codes for such FLIPs after the feature freeze should be carefully evaluated and require permissions from the release managers. - Further extending the feature freeze might also be an option, but I personally don't think it's necessary to block the release testing. Most of the recent API deprecation FLIPs require only minor changes that IHMO can barely affect the stability of the codebase.
But this should be the release managers' call. Looking forward to your opinions. Best, Xintong On Fri, Jul 21, 2023 at 4:25 PM Matthias Pohl <matthias.p...@aiven.io.invalid> wrote: > The feature freeze was postponed to July 24 (end of this week in > Europe/early morning Monday in East Asia) in [1]. What's the 1.18 release > managers' take on all the FLIPs that were recently started and require some > deprecation work (which ideally should go into 1.18)? How does that work > with the feature freeze happening by the end of this week? > > - Do we plan to extend the feature freeze to allow deprecation changes to > go in? > - Do we consider depreciation work to be "not a new feature" which means > that we're ok with merging them after the feature freeze? > > Best, > Matthias > > [1] https://lists.apache.org/thread/9fck1m5llrnv5gx1od05tzx84oy0b4z0 >
