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