[DISCUSS] Planning Release 1.4

[Robert Metzger]

Hi all,

Flink 1.2 was released on February 2, Flink 1.3 on June 1, which means
we've managed to release Flink 1.3 in almost exactly 4 months!

For the 1.4 release, I've put the following deadlines into the wiki [1]:

*Next scheduled major release*: 1.4.0
*Feature freeze (branch forking)*:  4. September 2017
*Code freeze (first voting RC)*:  18 September 2017
*Release date*: 29 September 2017

I'll try to send a message every month into this thread to have a countdown
to the next feature freeze.


[1]
https://cwiki.apache.org/confluence/display/FLINK/Flink+Release+and+Feature+Plan

[Greg Hogan]

I’d like to propose keeping the same schedule but move branch forking from the feature freeze to the code freeze. The early fork required duplicate verification and commits for numerous bug fixes and minor features which had been reviewed but were still queued. There did not look to be much new development merged to master between the freezes.

Greg

> On Jun 1, 2017, at 11:26 AM, Robert Metzger <[hidden email]> wrote:
>
> Hi all,
>
> Flink 1.2 was released on February 2, Flink 1.3 on June 1, which means
> we've managed to release Flink 1.3 in almost exactly 4 months!
>
> For the 1.4 release, I've put the following deadlines into the wiki [1]:
>
> *Next scheduled major release*: 1.4.0
> *Feature freeze (branch forking)*:  4. September 2017
> *Code freeze (first voting RC)*:  18 September 2017
> *Release date*: 29 September 2017
>
> I'll try to send a message every month into this thread to have a countdown
> to the next feature freeze.
>
>
> [1]
> https://cwiki.apache.org/confluence/display/FLINK/Flink+Release+and+Feature+Plan

[Robert Metzger]

I agree that it was quite annoying to merge everything to two branches.
But part of that problem was that many big features were merged last minute
and then fixed after the feature freeze.
In an ideal world, all features are stable, tested and documented when the
feature freeze happens and most commits go into master only.

I wonder if we can manage to merge queued minor features before the feature
freeze to avoid the issue in the future?

If we all agree that this doesn't work, we can also try to delay the
feature freeze. I just fear that this will make it harder to meet the
release deadline.


Robert

On Thu, Jun 1, 2017 at 6:05 PM, Greg Hogan <[hidden email]> wrote:

> I’d like to propose keeping the same schedule but move branch forking from
> the feature freeze to the code freeze. The early fork required duplicate
> verification and commits for numerous bug fixes and minor features which
> had been reviewed but were still queued. There did not look to be much new
> development merged to master between the freezes.
>
> Greg
>
>
> > On Jun 1, 2017, at 11:26 AM, Robert Metzger <[hidden email]> wrote:
> >
> > Hi all,
> >
> > Flink 1.2 was released on February 2, Flink 1.3 on June 1, which means
> > we've managed to release Flink 1.3 in almost exactly 4 months!
> >
> > For the 1.4 release, I've put the following deadlines into the wiki [1]:
> >
> > *Next scheduled major release*: 1.4.0
> > *Feature freeze (branch forking)*:  4. September 2017
> > *Code freeze (first voting RC)*:  18 September 2017
> > *Release date*: 29 September 2017
> >
> > I'll try to send a message every month into this thread to have a
> countdown
> > to the next feature freeze.
> >
> >
> > [1]
> > https://cwiki.apache.org/confluence/display/FLINK/
> Flink+Release+and+Feature+Plan
>
>

[Stephan Ewen]

I agree with these points.

My personal take is that we tried to be a bit too strict with the "date to
fork" and "date to release" and it got a bit in the way of development and
testing.

On Fri, Jun 2, 2017 at 11:15 AM, Robert Metzger <[hidden email]> wrote:

> I agree that it was quite annoying to merge everything to two branches.
> But part of that problem was that many big features were merged last minute
> and then fixed after the feature freeze.
> In an ideal world, all features are stable, tested and documented when the
> feature freeze happens and most commits go into master only.
>
> I wonder if we can manage to merge queued minor features before the feature
> freeze to avoid the issue in the future?
>
> If we all agree that this doesn't work, we can also try to delay the
> feature freeze. I just fear that this will make it harder to meet the
> release deadline.
>
>
> Robert
>
> On Thu, Jun 1, 2017 at 6:05 PM, Greg Hogan <[hidden email]> wrote:
>
> > I’d like to propose keeping the same schedule but move branch forking
> from
> > the feature freeze to the code freeze. The early fork required duplicate
> > verification and commits for numerous bug fixes and minor features which
> > had been reviewed but were still queued. There did not look to be much
> new
> > development merged to master between the freezes.
> >
> > Greg
> >
> >
> > > On Jun 1, 2017, at 11:26 AM, Robert Metzger <[hidden email]>
> wrote:
> > >
> > > Hi all,
> > >
> > > Flink 1.2 was released on February 2, Flink 1.3 on June 1, which means
> > > we've managed to release Flink 1.3 in almost exactly 4 months!
> > >
> > > For the 1.4 release, I've put the following deadlines into the wiki
> [1]:
> > >
> > > *Next scheduled major release*: 1.4.0
> > > *Feature freeze (branch forking)*:  4. September 2017
> > > *Code freeze (first voting RC)*:  18 September 2017
> > > *Release date*: 29 September 2017
> > >
> > > I'll try to send a message every month into this thread to have a
> > countdown
> > > to the next feature freeze.
> > >
> > >
> > > [1]
> > > https://cwiki.apache.org/confluence/display/FLINK/
> > Flink+Release+and+Feature+Plan
> >
> >
>

[Eron Wright-2]

Aside from the release management aspect, shall we discuss the major themes
of 1.4?

On Thu, Jun 1, 2017 at 8:26 AM, Robert Metzger <[hidden email]> wrote:

> Hi all,
>
> Flink 1.2 was released on February 2, Flink 1.3 on June 1, which means
> we've managed to release Flink 1.3 in almost exactly 4 months!
>
> For the 1.4 release, I've put the following deadlines into the wiki [1]:
>
> *Next scheduled major release*: 1.4.0
> *Feature freeze (branch forking)*:  4. September 2017
> *Code freeze (first voting RC)*:  18 September 2017
> *Release date*: 29 September 2017
>
> I'll try to send a message every month into this thread to have a countdown
> to the next feature freeze.
>
>
> [1]
> https://cwiki.apache.org/confluence/display/FLINK/
> Flink+Release+and+Feature+Plan
>

[Stephan Ewen]

Hi Eron!

Looking at the mailing list and JIRA the threads that are currently
happening:

  - Flip 6 and resource elasticity (towards dynamic scaling)
  - Dependency rework (hide dependencies, rework classloading, etc)
  - Kafka exactly once producer and partition discovery
  - General robustness enhancements of checkpointing, incremental
checkpoints
  - Some scalability and zero-tuning enhancements (RPC, blob server)
  - A lot of Streaming SQL stuff, like joins and CEP integration

There is a lot more, these are just some current threads...

On Mon, Jul 24, 2017 at 6:49 PM, Eron Wright <[hidden email]> wrote:

> Aside from the release management aspect, shall we discuss the major themes
> of 1.4?
>
> On Thu, Jun 1, 2017 at 8:26 AM, Robert Metzger <[hidden email]>
> wrote:
>
> > Hi all,
> >
> > Flink 1.2 was released on February 2, Flink 1.3 on June 1, which means
> > we've managed to release Flink 1.3 in almost exactly 4 months!
> >
> > For the 1.4 release, I've put the following deadlines into the wiki [1]:
> >
> > *Next scheduled major release*: 1.4.0
> > *Feature freeze (branch forking)*:  4. September 2017
> > *Code freeze (first voting RC)*:  18 September 2017
> > *Release date*: 29 September 2017
> >
> > I'll try to send a message every month into this thread to have a
> countdown
> > to the next feature freeze.
> >
> >
> > [1]
> > https://cwiki.apache.org/confluence/display/FLINK/
> > Flink+Release+and+Feature+Plan
> >
>