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.
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
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 2
(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 work
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 d
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 fe
