> This is by design. Most of these are @Public APIs that we had to carry > around until Flink 2.0, because that was the initial guarantee that we > gave people. >
True, I knew @Public APIs could not be removed before the next major release. I meant house cleaning without violation of these annotations' design concept. i.e especially cleaning up for @PublicEvolving APIs since they are customer-facing. Regular cleaning up with all other @Experimental and @Internal APIs would be even better, if there might be some APIs marked as @deprecated. Best regards, Jing On Tue, Jun 13, 2023 at 4:25 PM Chesnay Schepler <ches...@apache.org> wrote: > On 13/06/2023 12:50, Jing Ge wrote: > > One major issue we have, afaiu, is caused by the lack of > housekeeping/house > > cleaning, there are many APIs that were marked as deprecated a few years > > ago and still don't get removed. Some APIs should be easy to remove and > > others will need some more clear rules, like the issue discussed at [1]. > This is by design. Most of these are @Public APIs that we had to carry > around until Flink 2.0, because that was the initial guarantee that we > gave people. > > As for the FLIP, I like the idea of explicitly writing down a > deprecation period for APIs, particularly PublicEvolving ones. > For Experimental I don't think it'd be a problem if we could change them > right away, > but looking back a bit I don't think it hurts us to also enforce some > deprecation period. > 1 release for both of these sound fine to me. > > > My major point of contention is the removal of Public APIs between minor > versions. > This to me would a major setback towards a simpler upgrade path for users. > If these can be removed in minor versions than what even is a major > release? > The very definition we have for Public APIs is that they stick around > until the next major one. > Any rule that theoretically allows for breaking changes in Public API in > every minor release is in my opinion not a viable option. > > > The "carry recent Public APIs forward into the next major release" thing > seems to presume a linear release history (aka, if 2.0 is released after > 1.20, then there will be no 1.21), which I doubt will be the case. The > idea behind it is good, but I'd say the right conclusion would be to not > make that API public if we know a new major release hits in 3 months and > is about to modify it. With a regular schedule for major releases this > wouldn't be difficult to do. >
