Thanks for the response, Qingsheng. I'm fine with not allowing new features after the 1.18 freeze.
Just want to double-check, how about the FLIPs that purely mark things as `@Deprecated` without adding anything new? Do we agree to treat them as "not new features"? Best, Xintong On Wed, Jul 26, 2023 at 12:08 PM Qingsheng Ren <re...@apache.org> wrote: > (Sorry for resending this. I forgot to cc the dev mailing list) > > Hi Matthias and Xintong, > > Thanks for raising the question! We brought it to the 1.18 release sync on > Jul 26th, and we decided to stick to the original schedule of 1.18 and will > not accept new features, including those deprecation works. We don't see > benefits to 2.0 clearly about giving another several weeks squeezing these > deprecations into 1.18. I checked the latest FLIPs and most of them have > not been voted on yet, so we are a bit concerned about the overhead of > evaluating these cases and potentially delaying the release of 1.18. > > What about we have a better, clearer plan on deprecations at the beginning > of the next release cycle, considering FLIP-321 and 2.0 working items are > finalized quite nearing the feature freeze of 1.18? > > Best, > Qingsheng, Jing, Konstantin and Sergey > > On Wed, Jul 26, 2023 at 12:06 PM Qingsheng Ren <re...@apache.org> wrote: > >> Hi Matthias and Xintong, >> >> Thanks for raising the question! We brought it to the 1.18 release sync >> on Jul 26th, and we decided to stick to the original schedule of 1.18 and >> will not accept new features, including those deprecation works. We don't >> see benefits to 2.0 clearly about giving another several weeks squeezing >> these deprecations into 1.18. I checked the latest FLIPs and most of them >> have not been voted on yet, so we are a bit concerned about the overhead of >> evaluating these cases and potentially delaying the release of 1.18. >> >> What about we have a better, clearer plan on deprecations at the >> beginning of the next release cycle, considering FLIP-321 and 2.0 working >> items are finalized quite nearing the feature freeze of 1.18? >> >> Best, >> Qingsheng, Jing, Konstantin and Sergey >> >> On Fri, Jul 21, 2023 at 5:28 PM Xintong Song <tonysong...@gmail.com> >> wrote: >> >>> 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 >>>> >>>
