+1 On using "Fix Version" for that. I always try to use that already for things that need fixing in the next release. Also "Blocker" is a thing there.
> On 30. Aug 2017, at 20:29, Eron Wright <eronwri...@gmail.com> wrote: > > I definitely think the conversation must happen in the context of the > expected feature-set. JIRA is our friend here. I like the idea of > using the "Fix Version" to identify the set from which the leadership can > formulate an estimate. I would suggest that folks update their tasks > accordingly. WDTY? > > On Wed, Aug 30, 2017 at 10:21 AM, Greg Hogan <c...@greghogan.com> wrote: > >> 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 >> >>
