A side effect of the amount of deprecation FLIPs is that it takes up quite a bit of time to verify them (if you want the community to do a proper check). Individual FLIPs might not be that big. And of course, one could argue that we can distribute the work to multiple people as a community effort. But it puts pressure on the community to focus on that topic and might remove capacity from the community to do release testing for 1.18 or fixing bugs that pop up.
I see a risk in lowering the quality of the 1.18 release and the deprecation work (where we then might have to do another round if we missed something) with no additional value because deprecation work still needs to be done in 1.19. In this sense, pushing non-functional changes to master might be ok codewise - but they might come with other implications. Matthias On Wed, Jul 26, 2023 at 9:53 AM Qingsheng Ren <re...@apache.org> wrote: > Hi Xintong, > > It's fine to me to accept deprecations that only add annotations and > JavaDocs. We'll make a formal announcement later about 1.18 feature freeze > and plans on x-team testing, and please let us know (make a reply in that > thread) before you wanna do the deprecation action. > > Best, > Qingsheng > > On Wed, Jul 26, 2023 at 1:06 PM Xintong Song <tonysong...@gmail.com> > wrote: > > > 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 > > >>>> > > >>> > > >
