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 >
