flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vasiliki Kalavri <vasilikikala...@gmail.com>
Subject Re: [DISCUSS] Time-based releases in Flink
Date Wed, 18 Jan 2017 09:25:25 GMT
Hi Robert,

thanks a lot for starting this discussion and for putting together the wiki
pages.
This proposal makes a lot of sense to me.

Big +1 for merging only features which are tested and *documented*.

I believe that having a clear timeline will not only make users happier but
also contributors more engaged. With the current unpredictability, it is
hard to book time aside to help with testing a release candidate. I hope
that knowing exactly when that needs to happen will help us plan our own
time better and help out more.

Cheers,
-Vasia.

On 18 January 2017 at 09:57, Tzu-Li (Gordon) Tai <tzulitai@apache.org>
wrote:

> Hi Robert,
>
> Thanks for bringing up the discussion. I like the proposal.
>
> Regarding some of the downsides mentioned in the wiki:
>
> 1. Features that don’t make it in time with the feature freeze:
> I think that’s ok, as long as we’re consistent with the schedules for the
> next release. This way users waiting for that particular features will
> still be able to rely on the fact that the feature will be included in 4
> months.
>
> 2. Frequent releases mean bug fix releases for older branches:
> You mentioned in the email that “old releases are supported for 6 months
> by the community”, but not in the wiki. If this is strictly followed, that
> means we’ll at most be supporting 2 previous major release versions (ex. as
> soon as 1.4.0 comes out, we’ll still be supporting bugfixes for 1.3.0, as
> well as 1.2.0 for another 2 months).
> This might seem a bit odd, so perhaps we can stick to something like
> “support bugfixes for the previous 2 major releases”? Ex. Once 1.4.0 comes
> out, we’ll continue to support only 1.4.0 and 1.3.0.
> Supporting bugfixes for 2 major versions seems workable, and this way
> users can also have a “buffer” that they should not fall behind releases
> for more than 2 major versions (8 months) and preplan upgrades.
>
> - Gordon
>
> On January 18, 2017 at 9:19:41 AM, Robert Metzger (rmetzger@apache.org)
> wrote:
>
> Hi all!
>
> Since the 1.2.0 release is about to come out, I would like to propose a
> change in the way we do releases in the Flink community.
>
> In my opinion, the current model leads to dissatisfaction among users and
> contributors, because releases are really not predictable. A recent example
> for the issues with our current model are the FLIP-6 changes we wanted to
> merge to master, a few weeks before the first RC for 1.2.0. Also, there
> were some emails on the mailing lists asking for a release date.
>
> In order to change that, I’m proposing to follow a strictly time-based
> release model. Other open source projects like Ubuntu, Cassandra, Spark or
> Kafka are following that model as well, and I think we should try it out as
> an experiment for the 1.3.0 release.
>
> I’m proposing to:
>
> -
>
> Do a Flink release every 4 months
> -
>
> Cycle:
> -
>
> 3 months development
> -
>
> 1 month before the release: Feature freeze. Create release branch
> with RC0, start testing. Only fixes, tests and minor improvements are
> allowed in.
> -
>
> 2 weeks before the release: Code freeze. Start voting. Only fixes for
> blockers are allowed in.
> -
>
> Forbid blocking a release because a feature is not done yet.
> -
>
> Features are merged to master, when they are tested and documented, to
> have an always stable master
> -
>
> Bugfix releases are done as needed.
> -
>
> Old releases are supported for 6 months by the Flink community with
> critical bug fixes
>
>
> This means, that we would have the following release dates:
>
> (Flink 1.3.0 by end of January 2017)
>
> Flink 1.4.0 by end of May 2017
>
> Flink 1.5.0 by end of September 2017
>
> Flink 1.6.0 by end of January 2018
>
> I’ve put some more details including some pro’s and con’s into our wiki.
> The page is based on Kafka’s time-based release wiki page (Kafka also
> recently started following a strictly time-based model)
>
> https://cwiki.apache.org/confluence/display/FLINK/Time-based+releases
>
>
> Once we’ve agreed on following that model, I’ll update the release plan
> page accordingly:
> https://cwiki.apache.org/confluence/display/FLINK/
> Flink+Release+and+Feature+Plan
>
>
> Please let me know what you think about this idea!
>
> Regards,
>
> Robert
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message