The discuss thread for tightening the stability guarantees for
@PublicEvolving classes can be found here [1]
[1]
https://lists.apache.org/thread.html/rb0d0f887b291a490ed3773352c90ddf5f11e3d882dc501e3b8cf0ed0%40%3Cdev.flink.apache.org%3E
Cheers,
Till
On Thu, May 14, 2020 at 10:13 AM Till Rohrmann
I agree with the pragmatic solution.
Concerning the stability guarantees I will start a separate discussion
thread whether to provide stricter guarantees or not.
Cheers,
Till
On Wed, May 13, 2020 at 10:13 PM Thomas Weise wrote:
> On Wed, May 13, 2020 at 1:02 PM Piotr Nowojski
> wrote:
>
> > H
On Wed, May 13, 2020 at 1:02 PM Piotr Nowojski wrote:
> Hi,
>
> > For the future, it would be great to eliminate the possibility of
> > incompatible changes to user-facing classes for patch releases though.
> > Running japicmp as part of CI might be a good option.
>
> I guess the whole point of P
Hi,
> For the future, it would be great to eliminate the possibility of
> incompatible changes to user-facing classes for patch releases though.
> Running japicmp as part of CI might be a good option.
I guess the whole point of PublicEvolving classes is to allow us for the
breaking compatibility
+1 to improve and eliminate the possibility of incompatible changes to
user-facing classes for patch releases.
The PR for 1.10.1 release [1] is already updated, please kindly let me know
if any further comments.
I plan to merge the PR and officially announce the release in ~ half an
hour if no ob
For release branches, it would be good to not exclude PublicEvolving from
checking, by default [1].
There may be instances where it is necessary to make exceptions to fix a
critical bug, but those could be whitelisted.
Similarly, it might be good to blacklist dependency changes for patch
releases
We are running japicmp in CI; we just don't check anything that is
PublicEvolving.
On 13/05/2020 18:04, Thomas Weise wrote:
+1 for the release note addition
Historically Flink X.Y.0 releases have been prone to issues like this. And
I suspect that many users would prefer to upgrade to X.Y.1 due
+1 for the release note addition
Historically Flink X.Y.0 releases have been prone to issues like this. And
I suspect that many users would prefer to upgrade to X.Y.1 due to other
bugs that need to be shaken out.
For the future, it would be great to eliminate the possibility of
incompatible chang
Thanks Seth, comment received, will add it into the release note.
Best Regards,
Yu
On Wed, 13 May 2020 at 22:54, Seth Wiesman wrote:
> +1 Ufuk's pragmatic solution to update the release notes with a public
> notice, I have commented on the release notes PR.
>
> https://github.com/apache/flink-
+1 Ufuk's pragmatic solution to update the release notes with a public
notice, I have commented on the release notes PR.
https://github.com/apache/flink-web/pull/330
Seth
On Wed, May 13, 2020 at 8:30 AM Chesnay Schepler wrote:
> IIRC @PublicEvolving had no /real/ guarantees, from the 1.0.0 ann
IIRC @PublicEvolving had no /real/ guarantees, from the 1.0.0 announcement:
/"Flink 1.0.0 introduces interface stability annotations for API classes
and methods. Interfaces defined as //|@Public|//are guaranteed to remain
stable across all releases of the 1.x series. The
//|@PublicEvolving|//a
A small addendum: The project currently enforces only binary compatibility
for classes which are annotated with @Public. The StreamingFileSink is
annotated with @PublicEvolving.
I am not sure whether the community properly defined what kind of
stability/compatibility guarantees we provide for @Pub
Thanks for the analysis Till.
1/ I think breaking binary compatibility is acceptable between minor
releases (1.10 -> 1.11) as you suggested since the API is marked
as @PublicEvolving.
2/ I'm quite torn about how to proceed with the 1.10.x patch release, but
slightly leaning towards the "pragmatic
Thanks for reporting this issue Seth. This is indeed a big problem.
I looked into the problem and it seems we have the following situation:
# 1.9.x --> 1.10.0
There is an API breaking change between 1.9.x and 1.10 due FLINK-13864
because it introduced another generic parameter. I expected only f
We also noticed that and had to make an adjustment downstream.
It would be good to mention this in the release notes (if that's not
already the case).
Thomas
On Tue, May 12, 2020 at 10:06 AM Seth Wiesman wrote:
> Hi Everyone,
>
> I realize I'm about 7 hours late but I just realized there is a
15 matches
Mail list logo
