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