Hi all, +1 for this change. I see it as the responsibility of the community to make one more bugfix release available which for me is clear from the proposed text.
Best regards, Martijn On Tue, Feb 21, 2023 at 10:08 AM Danny Cranmer <dannycran...@apache.org> wrote: > Thanks all for the feedback. > > @Piotr/@Matthias my intention was to relax the support policy rather than > enforce patch releases to be performed immediately. I see pros and cons to > both, if we do not do the release immediately it may be dragged out, if we > enforce it, then it puts more burden on the release manager. A compromise > could be for the release manager to start the discussion thread and > volunteer to be release manager if they have capacity. We can update the > release process [1] to include this final step. > > In summary I am proposing the following: > - Support policy += "Upon release of a new Flink minor version, the > community will perform one final bugfix release for resolved > critical/blocker issues in the Flink version losing support." > - Release process += Add a step to start the discussion thread for the > final 1.n-2 patch version, IF there are resolved critical/blocking issues. > > To clarify, major/minor bug fixes are out of scope of this policy. > > If we are aligned I will start a vote thread. > > Thanks, > Danny > > [1] > https://cwiki.apache.org/confluence/display/FLINK/Creating+a+Flink+Release > > > > On Mon, Feb 20, 2023 at 3:47 PM Piotr Nowojski <pnowoj...@apache.org> > wrote: > > > +1 for the proposal, it makes sense to me. > > > > Re Matthias, I think ideally it would be better for the minor release > > manager to do the final bug fix, so that we have a clear person that's > > responsible for that. Otherwise I have some fear that we would forget > about > > doing that. But I'm fine trying it out the way Matthias proposed, maybe > I'm > > worrying over nothing. > > > > Best, > > Piotrek > > > > pon., 20 lut 2023 o 12:34 Matthias Pohl <matthias.p...@aiven.io.invalid> > > napisał(a): > > > > > +1 > > > Thanks for picking it up, Danny. Your change makes sense. One question, > > > though: The phrase makes it sound like we're doing it mandatorily. With > > > this in mind, I would see the responsibility on the minor-release > release > > > managers' side (in your example 1.17). I would prefer to have it > > decoupled > > > to reduce the amount of responsibilities on the minor-release release > > > manager's side. Therefore, I'd propose a slightly different phrasing: > > > "Upon release of a new Flink minor version, the community encourages to > > > perform a final bugfix release for resolved critical/blocker issues in > > the > > > Flink version losing support." > > > > > > This phrasing implies that the final flush-out patch release is still > > > decoupled from the minor release. > > > > > > On Mon, Feb 20, 2023 at 9:02 AM weijie guo <guoweijieres...@gmail.com> > > > wrote: > > > > > > > Thanks Danny for the proposal~ > > > > > > > > +1 for this. In particular, we still have some users using relatively > > > early > > > > versions of flink. > > > > > > > > Best regards, > > > > > > > > Weijie > > > > > > > > > > > > yuxia <luoyu...@alumni.sjtu.edu.cn> 于2023年2月20日周一 14:51写道： > > > > > > > > > +1 > > > > > Thanks for the proposal. > > > > > > > > > > Best regards, > > > > > Yuxia > > > > > > > > > > ----- 原始邮件 ----- > > > > > 发件人: "Weihua Hu" <huweihua....@gmail.com> > > > > > 收件人: "dev" <dev@flink.apache.org> > > > > > 发送时间: 星期一, 2023年 2 月 20日 下午 2:36:08 > > > > > 主题: Re: [DISCUSS] Flink minor version support policy for old > releases > > > > > > > > > > +1 > > > > > > > > > > Thanks for the proposal, this is valuable for stability. > > > > > > > > > > Best, > > > > > Weihua > > > > > > > > > > > > > > > On Mon, Feb 20, 2023 at 10:52 AM Dong Lin <lindon...@gmail.com> > > wrote: > > > > > > > > > > > This makes a lot of sense. Thanks Danny for the proposal! > > > > > > > > > > > > +1 > > > > > > > > > > > > On Sat, Feb 18, 2023 at 12:52 AM Danny Cranmer < > > > > dannycran...@apache.org> > > > > > > wrote: > > > > > > > > > > > > > Hello all, > > > > > > > > > > > > > > As proposed by Matthias in a separate thread [1], I would like > to > > > > > start a > > > > > > > discussion on changing the policy wording to include the > release > > of > > > > bug > > > > > > > fixes during their support window. Our current policy [2] is to > > > only > > > > > > > support the latest two minor versions: " If 1.17.x is the > current > > > > > > release, > > > > > > > 1.16.y is the previous minor supported release. Both versions > > will > > > > > > receive > > > > > > > bugfixes for critical issues.". However there may be bug fixes > > that > > > > > have > > > > > > > been resolved but not released during their support window. > > > Consider > > > > > this > > > > > > > example: > > > > > > > 1. Current Flink versions are 1.15.3 and 1.16.1 > > > > > > > 2. We fix bugs for 1.15.3 > > > > > > > 3. 1.17.0 is released > > > > > > > 4. The 1.15 bug fixes will now not be released unless we get an > > > > > exception > > > > > > > > > > > > > > The current process is subject to race conditions between > > releases. > > > > > > Should > > > > > > > we upgrade the policy to allow bugfix releases to support > issues > > > that > > > > > > were > > > > > > > resolved during their support window. I propose we update the > > > policy > > > > to > > > > > > > include: > > > > > > > > > > > > > > "Upon release of a new Flink minor version, the community will > > > > perform > > > > > > one > > > > > > > final bugfix release for resolved critical/blocker issues in > the > > > > Flink > > > > > > > version losing support." > > > > > > > > > > > > > > Let's discuss. > > > > > > > > > > > > > > Thanks, > > > > > > > Danny > > > > > > > > > > > > > > [1] > > > https://lists.apache.org/thread/019wsqqtjt6h0cb81781ogzldbjq0v48 > > > > > > > [2] > > > > > > > > > https://flink.apache.org/downloads.html#update-policy-for-old-releases > > > > > > > > > > > > > > > > > > > > > > > > > > > >
