Hi, sorry, my previous message was confusing. I suggest to release a new Flink version all 3 months. BUT, the 0.7-incubating release is going to be feature freeze in 3 weeks because 0.6-incubating was more about getting the release infra set up and the apache rename out. The last release that contained a lot of features was 0.5 and it was released on May 29. So aiming for end of September for the next feature release should be somehow in the schedule.
Robert On Wed, Sep 3, 2014 at 11:47 AM, Ufuk Celebi <[email protected]> wrote: > Hey Robert, > > +1 to frequent regular frequent major releases (I guess you meant 3 weeks > and not 3 months, right?). > > Ufuk > > > On Tue, Sep 2, 2014 at 9:29 PM, Robert Metzger <[email protected]> > wrote: > > > Hi, > > I agree with Fabian that the list of features is a lot of work. I would > > prefer to have frequent regular major releases (say 3 months schedule). > > This way, users can quickly access the latest features and we don't force > > them to use SNAPSHOT versions. > > Also, releases draw attention to our project. > > > > I would suggest to do a feature freeze on September 24 (3 weeks from now) > > and start the vote a few days afterwards. I assume that at least some of > > the suggested 7 features of the release are ready. > > > > Robert > > > > > > On Wed, Aug 27, 2014 at 9:20 PM, Fabian Hueske <[email protected]> > wrote: > > > > > I agree that these should be features to add soon, but I'm a bit > doubtful > > > that we will have the next release in 5 weeks if we want to include all > > of > > > this. > > > > > > I think we should either have a feature- or time-oriented release plan. > > > If we want to have a fixed release date, we could make a feature stop 1 > > > week (or so) in advance, include what's in until then and continue to > > > release every n weeks. > > > Or we make a list of what should be in the next release and try to > give a > > > reasonable time estimate for that (which didn't work out so well in the > > > past.... ;-) ) > > > > > > But having both, a close deadline and a long list of complex features > > will > > > not work out well, IMO. > > > > > > Just my 2 cents, Fabian > > > > > > > > > 2014-08-27 19:49 GMT+02:00 Stephan Ewen <[email protected]>: > > > > > > > This is a nice list. > > > > > > > > I would like to add: > > > > > > > > - Rework JobManager internals to support incremental program > rollout & > > > > execution > > > > - First parts of dynamic memory assignments > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Aug 27, 2014 at 7:21 PM, Robert Metzger <[email protected] > > > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > since we have our release infrastructure in place now, I would > > suggest > > > to > > > > > aim for a 0.7-incubating release in the near future (say 3-5 > weeks). > > > > > While 0.6-incubating was mainly about getting the release infra / > > legal > > > > > stuff sorted out, I think it would be nice to have a "feature" > > release > > > > > soon. > > > > > > > > > > The following new features would make a great 0.7-incubating > release: > > > > > - *Flink Streaming* "Beta Preview". I would suggest to ship the > > > > streaming, > > > > > but clearly mark it as a preview in the documentation. > > > > > -* Java API Pojo improvements*: Code generation, key selection > > using a > > > > > string-expression: > https://issues.apache.org/jira/browse/FLINK-1032 > > > > > - *Reworked Scala API*. Bring the Scala API in sync with the > latest > > > > > developments in the Java API: > > > > > https://issues.apache.org/jira/browse/FLINK-641 > > > > > -* Akka-based RPC service*: > > > > > https://issues.apache.org/jira/browse/FLINK-1019 > > > > > - *Kryo-based serialization*. This feature has been requested by > > many > > > > > users. Mostly because they wanted to use Collections inside POJOs: > > > > > https://issues.apache.org/jira/browse/FLINK-610 > > > > > > > > > > > > > > > Opinions? > > > > > > > > > > > > > > >
