I forgot to start the VOTE after 24 hours. However, I checked again Apache's voting rules [1] and code changes require consensus. So a -1 vote by a PMC member effectively is a veto. I don't have the impression from the discussion that we have a clear majority for one approach, so a VOTE thread would quickly turn into another big discussion thread.
Let me summarize the options at hand: #1 Break the DataStream API, by changing the return type of the apply() method #2 Keep the API and ask users to manually cast the return type of apply() to change the parallelism #3 Introduce a deprecated with() method that returns the correct type I prefer #2, because I think the should not break the API. We had some other API breaking discussions and we always found a solution. [1] http://www.apache.org/foundation/voting.html#votes-on-code-modification On Mon, Aug 15, 2016 at 12:21 PM, Robert Metzger <rmetz...@apache.org> wrote: > I would like have a decision on this so that we can merge the pull request. > > If we can not come up with a solution everybody agrees, and nobody rejects > the VOTE, I'll start a VOTE thread in 24 hours. > > > On Tue, Aug 9, 2016 at 3:57 PM, Till Rohrmann <trohrm...@apache.org> > wrote: > >> 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 >> > > >> > >> > >
