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 > >>>> > >>> >
