Hi, I think this is an important question that will surely come up in some cases in the future.
I see your point Robert, that we have promised api compatibility for 1.x.y releases, but I am not sure that this should cover things that are clearly just unintended errors in the api from our side. I am not sure what would be the right action regarding issues like this in the future. Gyula Chesnay Schepler <ches...@apache.org> ezt írta (időpont: 2016. márc. 13., V, 12:37): > On 13.03.2016 12:14, Robert Metzger wrote: > > I think its too early to fork off a 2.0 branch. I have absolutely no idea > > when a 2.0 release becomes relevant, could be easily a year from now. > at first i was going to agree with Robert, but then...I mean the issue > with not allowing breaking changes > is that effectively this means we won't work on these issues until 2.0 > comes around. Since otherwise, > the contributor would have to stash that change themselves in their own > repository for god-knows how long. > Chances are that work will go to waste anyway because they forget / > delete it. > > having a central place (not necessarily a separate branch, maybe a repo > with a separate branch for every commit) > where we can stash this work could prove useful; instead of starting to > work on these issues all at once for 2.0, > we could save some work by only having to rebase them in one way or > another. > > > And for tracking API breaking changes, maybe it makes sense to create a > > 2.0.0 version in JIRA and set the "fix-for" for the issue to 2.0. > +1 for adding a 2.0.0 version tag/. /This is the perfect use-case for it.// > > > > On Sun, Mar 13, 2016 at 12:08 PM, Márton Balassi < > balassi.mar...@gmail.com> > > wrote: > > > >> Ok, if that is what we promised let's stick to that. > >> Then would you suggest to open a release-2.0 branch and merge it there? > >> > >> On Sun, Mar 13, 2016 at 11:43 AM, Robert Metzger <rmetz...@apache.org> > >> wrote: > >> > >>> Hey, > >>> JIRA was down for quite a while yesterday. Sadly, I don't think we can > >>> merge the change because its API breaking. > >>> One of the promises of the 1.0 release is that we are not breaking any > >> APIs > >>> in the 1.x.y series of Flink. We can fix those issues with a 2.x > release. > >>> > >>> On Sun, Mar 13, 2016 at 5:27 AM, Márton Balassi < > >> balassi.mar...@gmail.com> > >>> wrote: > >>> > >>>> The JIRA issue is FLINK-3610. > >>>> > >>>> On Sat, Mar 12, 2016 at 8:39 PM, Márton Balassi < > >>> balassi.mar...@gmail.com> > >>>> wrote: > >>>> > >>>>> I have just come across a shortcoming of the streaming Scala API: it > >>>>> completely lacks the Scala implementation of the DataStreamSink and > >>>>> instead the Java version is used. [1] > >>>>> > >>>>> I would regard this as a bug that needs a fix for 1.0.1. > >> Unfortunately > >>>>> this is also api-breaking. > >>>>> > >>>>> Will post it to JIRA shortly - but issues.apache.org is unresponsive > >>> for > >>>>> me currently. Wanted to raise the issue here as it might affect the > >>> api. > >>>>> [1] > >> https://github.com/apache/flink/blob/master/flink-streaming-scala > >>>>> /src/main/scala/org/apache/flink/streaming/api/scala/DataStream.scala > >>>>> #L928-L929 > >>>>> > >
