That is a tough call but I'm personally leaning slightly towards not breaking the API and adding a note for the casting workaround.
My main concern is where do we set the limit for future API breaking issues? How critical does an issue has to be to be allowed to break the API? Currently, we have 10 API breaking issues for Flink 2.0 [1]. Why not including one of them as well? I think that backwards compatibility (source as well as binary) is really important for many users and we have the duty to live up to our promises. Imho, if things are API breaking, then we should indeed bump the major version, as Greg suggested. [1] https://issues.apache.org/jira/browse/FLINK-3957 Cheers, Till On Tue, Aug 9, 2016 at 2:20 PM, Greg Hogan <c...@greghogan.com> wrote: > I agree that expecting users to cast is undesirable. Upon changing the API, > why would we not mark the next release as 2.0? > > The same issue arose with Gabor's addition of hash-combine in the Scala > DataSet API where DataSet was returned rather than a specialized Operator. > The solution was to add an overloaded method. > > https://github.com/apache/flink/pull/1517/files#diff- > b1fea8d5283d978e9ccbc202dad36b5fR322 > > On Mon, Aug 8, 2016 at 10:11 AM, Stephan Ewen <se...@apache.org> wrote: > > > Hi all! > > > > We have a problem in the *DataStream API* around Windows for *CoGroup* > and > > *Join*. > > These operations currently do not allow to set a parallelism, which is a > > pretty heavy problem. > > > > To fix it properly, we need to change the return types of the coGroup() > and > > join() operations, which *breaks the binary compatibility* - it* retains > > source compatibility*, though. > > > > The pull request with the change is: > > https://github.com/apache/flink/pull/2305 > > > > There are very clumsy ways to work around this (custom casts in the user > > code or making the join() / coGroup() behave differently than the other > > operators) which we did not really think of as viable, because they would > > need to be changed again in the future once we pull the API straight > > (breaking even source compatibility then). > > > > *I would suggest to actually break the API* at that point (binary, not > > source) for *Flink 1.2* and add a big note in the release docs. An > > uncomfortable step, but the alternatives are quite bad, too. > > > > Have a look at what has been suggested in the pull request discussion and > > please let us know what you think about that so we can proceed. > > > > Greetings, > > Stephan > > >
