Yes, we will have more of these issues in the future and each issue will need a separate discussion. I don't think that clearly unintended errors (I hope we won't find any intended errors) are a sufficient reason to break stable a stable API. IMO, the question that needs to be answered how much of an issue it is (put it on a scale: bug > limitation > inconsistent API) and whether there are workarounds that avoid API breaking changes.
Cheers, Fabian 2016-03-13 19:06 GMT+01:00 Gyula Fóra <gyf...@apache.org>: > 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 > > >>>>> > > > > >
