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 e
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 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
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 wrote:
> I agree that it was quite annoying to merge everythi
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 com
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
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. Sept
