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 <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 >
