So this is a terminology problem.
*Flink does not follow the major.minor.patch naming scheme.*
x.y.z is minor, x.y.0 is major, x.0.0 has no name as of right now.
Public API's may be broken in x.0.0, and Till is not suggesting to
change this.
What he is suggesting is that:
Public APIs may only be broken in x.0.0; as is current policy.
PublicEvolving APIs may only be broken in x.0.0 and x.y.0, but not
x.y.z; this would be new.
On 14/05/2020 10:47, Xintong Song wrote:
Thanks for bring this discussion up, Till.
+1 for guaranteeing API + binary compatibility for @PublicEvolving classes
for bug fix releases.
I have a bit concern on the compatibility of @Public classes though.
According to the JavaDoc, @Public requires classes to be stable
across minor releases (x.y.z vs. x.u.v), but can be broken by across major
releases (x.y.z v.s u.v.w). Further tighten the stability will leave us no
chance to remove outdated APIs annotated as @Public. AFAIK, there are
already many APIs annotated as @Public that we intend to remove with the
release 2.x. E.g., some deprecated constants in ConfigConstants.
Thank you~
Xintong Song
On Thu, May 14, 2020 at 4:30 PM Till Rohrmann <trohrm...@apache.org> wrote:
Dear community,
in the latest 1.10.1 bug fix release I introduced a binary incompatible
change to a class which is annotated with @PublicEvolving [1]. While this
change is technically ok since we only provide API and binary compatibility
for @Public classes across releases, it raised the question whether we
can't do better.
For our users it might be surprising and really annoying that they cannot
simply upgrade to the latest bug fix release without recompiling the
program or even having to change the source code of an application. I
believe we would provide a much better experience if we ensured that bug
fix releases maintain API and binary compatibility also for @PublicEvolving
classes. Hence my proposal would be to tighten the stability guarantees the
following way:
* API + binary compatibility for @Public classes across all releases (x.y.z
is compatible to u.v.w)
* API + binary compatibility for @PublicEvolving classes for all bug fix
releases in a minor release (x.y.z is compatible to x.y.u)
This would entail that we can change @PublicEvolving classes only across
minor/major releases.
Practically this would mean that we enable the japicmp-maven-plugin
for @PublicEvolving for bug fix releases.
What do you think?
[1]
https://lists.apache.org/thread.html/r293768d13d08149d756e0bf91be52372edb444c317535d1d5a496c3e%40%3Cdev.flink.apache.org%3E
Cheers,
Till
