flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ufuk Celebi <...@apache.org>
Subject Re: [DISCUSS] Time-based releases in Flink
Date Wed, 18 Jan 2017 10:14:35 GMT
@Robert: I really like this. +1 to implement this after 1.2.0 is released. Small note about
your release dates: you started with 1.3.0 but probably meant 1.2.0 right?

On 18 January 2017 at 09:57:31, 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
View raw message