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.
