Haven’t seen much discussion here. I see the benefit of time-based deadlines but also of focussing on release functionality and stability.
I like the idea to keep the structure of time-based releases but soften the deadlines. The schedule would not be open-ended but we could wait on the completion and stability of major new features and also schedule around events like the upcoming Flink Forward. I would like to still fork the release branch as late as possible. Greg > On Aug 23, 2017, at 5:07 AM, Timo Walther <twal...@apache.org> wrote: > > I also think we shouldn't publish releases regularly, just to have a release > regularly. > > Maybe we can do time-based releases more flexible: Instead of feature-freeze > after 3 months, 1 month testing. We could do it like feature-freeze 3 months > after the last release, unlimited testing. This would limit us in not adding > too many features, but enables for proper testing for robust releases. What > do you think? > > Regards, > Timo > > Am 23.08.17 um 10:26 schrieb Till Rohrmann: >> Thanks for starting the discussion Stephan. I agree with you that the last >> release was probably a bit hasty due to the constraints we put on ourselves >> with the strict time based release. Therefore and because of some of the >> incomplete features, I would be in favour of loosening the strict deadline >> such that we have more time finishing our work and properly testing the >> release. Hard to tell, however, how much more time is needed. >> >> Cheers, >> Till >> >> On Tue, Aug 22, 2017 at 6:56 PM, Chen Qin <qinnc...@gmail.com> wrote: >> >>> I would be great to avoid immediate 1.x1 bug fixing release. It cause >>> confusion and raise quality concerns. >>> >>> Also, is there already way to communicate with Amazon EMR for latest >>> release speedy available? I may try to find someone work there is needed. >>> >>> Thanks >>> Chen >>> >>>> On Aug 22, 2017, at 9:32 AM, Stephan Ewen <se...@apache.org> wrote: >>>> >>>> Hi all! >>>> >>>> I want to bring up this discussion because we are approaching the date >>> when >>>> there would be a feature freeze following the time based release >>> schedule. >>>> To make it short, I would suggest to not follow the time-based schedule >>> for >>>> that release. There are a bunch of reasons bringing me to that view: >>>> >>>> - 1.3.0, which was very much pushed by the time-based schedule was not >>>> the best release we ever made. In fact, it had quite a few open issues >>> that >>>> required an immediate 1.3.1 followup and only 1.3.2 fixed some of them. >>>> >>>> - 1.3.2, which is in some sense what 1.3.0 should have been is only 2 >>>> weeks back >>>> >>>> - The delta since the last release is still quite small. One could argue >>>> to make a quick release and then soon another release after that, but >>>> releases still tie up quite a good amount of resources, so that would >>>> introduce a delay for much of the ongoing work. I am doubtful if this is >>> a >>>> good idea at this point. >>>> >>>> - The current master has still quite a bit of "ongoing work" that is not >>>> in perfect shape for a release, but could use some more weeks to provide >>>> real value to users. Examples are the dependency reworking, network stack >>>> enhancements, speedier state restore efforts, flip-6, exactly-once >>>> sinks/side-effects, and others. >>>> >>>> >>>> Alternatively, we could do what we did for 1.1 and 1.2, which is making >>> now >>>> a list of features we want in the release, and then projecting based on >>>> that when we fork off the 1.4 release branch. >>>> >>>> >>>> What do you think? >>>> >>>> >>>> Cheers, >>>> Stephan
