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

Reply via email to