In general, I like the idea of time-based releases. For the development process this would mean, that we would need to fork off feature branches and work on those until the feature can be merged back into master. We did that already in the past when porting the Table API to Apache Calcite and for the FLIP-6 development. For the Table API (where I was involved) that worked quite well, IMO.
@Robert, I think your release plan is off by 1 ;-) Cheers, Fabian 2017-01-18 9:19 GMT+01:00 Robert Metzger <rmetz...@apache.org>: > 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 >
