tions, it should be explicitly marked it
> >>>>> as @Internal.
> >>>>>
> >>>>> Thanks,
> >>>>> Zhu Zhu
> >>>>>
> >>>>> Yun Tang 于2020年5月15日周五 上午11:41写道：
> >>>>>
> &
s, and upgrading API stable level every 3 major
versions
should be better.
[1] https://flink.apache.org/downloads.html#flink
Best
Yun Tang
From: Xintong Song
Sent: Friday, May 15, 2020 11:04
To: dev
Subject: Re: [DISCUSS] Stability guarantees for @PublicEvolvi
>>> The minor suggestion is that I think two major release (which is x.y.0
>>>> as
>>>>> Chesnay clarified) might be a bit quick. From the release history [1],
>>>>> Flink bump major version every 3 ~ 6 months and two major release gap
>>>>&g
link bump major version every 3 ~ 6 months and two major release gap
> >> > could only be at least half a year.
> >> > I think half a year might be a bit too frequent for users to collect
> >> > enough feedbacks, and upgrading API stable level every 3 major
1],
>> > Flink bump major version every 3 ~ 6 months and two major release gap
>> > could only be at least half a year.
>> > I think half a year might be a bit too frequent for users to collect
>> > enough feedbacks, and upgrading API stable level every 3
be a bit too frequent for users to collect
> > enough feedbacks, and upgrading API stable level every 3 major versions
> > should be better.
> >
> > [1] https://flink.apache.org/downloads.html#flink
> >
> > Best
> > Yun Tang
> >
> >
> >
API stable level every 3 major versions
> should be better.
>
> [1] https://flink.apache.org/downloads.html#flink
>
> Best
> Yun Tang
>
>
>
> From: Xintong Song
> Sent: Friday, May 15, 2020 11:04
> To: dev
> Subject: Re: [DIS
Stability guarantees for @PublicEvolving classes
### Documentation on API compatibility policies
Do we have any formal documentation about the API compatibility policies?
The only things I found are:
- In the release announcement (take 1.10.0 as an example) [1]:
"This version is API-
### Documentation on API compatibility policies
Do we have any formal documentation about the API compatibility policies?
The only things I found are:
- In the release announcement (take 1.10.0 as an example) [1]:
"This version is API-compatible with previous 1.x releases for APIs
annota
I just want to throw in that we also need to rethink our policy towards
using @PublicEvolving.
We often introduce this easily (for every new feature) and rarely (almost
never) upgrade it to @Public. This kind of leads the idea behind stable API
guarantees ad absurdum.
I would suggest that we make
Thanks for the clarification.
+1 for keeping the current guarantees for @Public.
Thank you~
Xintong Song
On Thu, May 14, 2020 at 6:07 PM Till Rohrmann wrote:
> Sorry for the confusion. @Public classes are guaranteed to be stable
> between releases x.y.z and x.u.v (minor and bug fix release;
Sorry for the confusion. @Public classes are guaranteed to be stable
between releases x.y.z and x.u.v (minor and bug fix release; naming is
indeed a bit off here) and we can break it with major releases (x.0.0 and
y.0.0).
@Tison I would like to make what to include in the public API, hence what
to
Thanks for starting this discussion!
I agree turn on japicmp on PublicEvolving among bugfix releases is a nit
win.
@Xintong Song I think @Public guarantee is good
enough, the problem is a reachable 2.0 plan.
My concern is more on classes that have no annotation but our developers
regard as "som
I also like the proposal for keeping the binary compatibility of
@PublicEvolving for bugfix releases.
As for the @Public classes I think the current guarantees are good enough.
Best,
Dawid
On 14/05/2020 10:49, Jingsong Li wrote:
> Thanks Till for starting this discussion.
>
> +1 for enabling th
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 onl
Thanks Till for starting this discussion.
+1 for enabling the japicmp-maven-plugin for @PublicEvolving for bug fix
releases.
Bug fix should just be user imperceptible bug fix. Should not affect API
and binary compatibility.
And even PublicEvolving api change for "y" release, we should expose it i
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
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
18 matches
Mail list logo
