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