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 (rmetz...@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
