[DISCUSS] Flink 1.4 and time based release

[Stephan Ewen <se...@apache.org>]

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

Re: [DISCUSS] Flink 1.4 and time based release

[Piotr Nowojski <pi...@data-artisans.com>]

+1 for that, as long we will be consistent with it :)

> On Aug 31, 2017, at 12:22 PM, Aljoscha Krettek <al...@apache.org> wrote:
> 
> +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 <er...@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 <co...@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 <tw...@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 <qi...@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
>>> 
>>> 
> 

Re: [DISCUSS] Flink 1.4 and time based release

[Aljoscha Krettek <al...@apache.org>]

+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 <er...@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 <co...@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 <tw...@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 <qi...@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
>> 
>> 

Re: [DISCUSS] Flink 1.4 and time based release

[Eron Wright <er...@gmail.com>]

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 <co...@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 <tw...@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 <qi...@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
>
>

Re: [DISCUSS] Flink 1.4 and time based release

[Greg Hogan <co...@greghogan.com>]

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 <tw...@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 <qi...@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

Re: [DISCUSS] Flink 1.4 and time based release

[Timo Walther <tw...@apache.org>]

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 <qi...@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

Re: [DISCUSS] Flink 1.4 and time based release

[Till Rohrmann <tr...@apache.org>]

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 <qi...@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
>

Re: [DISCUSS] Flink 1.4 and time based release

[Chen Qin <qi...@gmail.com>]

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