Thanks a lot for the positive feedback so far. Thank you Fabian for spotting the off by one error in my email. "There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors." (https://twitter.com/codinghorror/status/ 506010907021828096?lang=en)
I agree with Fabian that this model could potentially lead to more feature branches in our repository. However, I think we should only do that for major features where many contributors are collaborating on. Using private development branches works equally well for smaller groups. I found that the frequent "flip6" branch rebases caused a lot of noise on the commits@flink list. Regarding the "bugfix guarantees": I agree that my proposal doesn't make so much sense. I actually got the same feedback from a draft of my email but forgot to change it before sending it out. I think supporting the current (1.1) and previous (1.0) major release is a doable guarantee. On Wed, Jan 18, 2017 at 10:25 AM, Vasiliki Kalavri < vasilikikala...@gmail.com> wrote: > 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 > > >
