Kindly reminder: The first release sync comes in 2 days. I've added a "Status / Follow-ups" section in the 2.0 Release wiki page [1]. If there's any topic you'd like to discuss, please append it to the "Discussion" list.
Best, Xintong [1] https://cwiki.apache.org/confluence/display/FLINK/2.0+Release On Tue, Aug 6, 2024 at 3:53 PM Xintong Song <tonysong...@gmail.com> wrote: > Hi devs, > > It has been more than 15 months since we kicked off the 2.0 release > plan[1]. With Flink 1.20 released last week, we finally entered the 2.0 > release cycle. > > As previously decided, Becket, Jark, Martijn and I will serve as the > release managers. We had a brief offline discussion (except for Martijn > who's on vacation), and here's the outcome. > > We are planning to have the *first release sync* at: > - 14:00-15:00, Aug 14 (Wed), BJT (GMT+8) > - 08:00-09:00, Aug 14 (Wed), CEST (GMT+2) > - 23:00-24:00, Aug 13 (Tues), PDT (GMT-7) > Everyone is welcome to join the release sync. You can subscribe to the > Google Calendar[2] or join the Google Meet[3] directly. You can also find > these links on the 2.0 Release wiki page [4]. > > There are a few things that we'd like to bring up for discussion in this > thread. *We'd like to hear your opinions before the release sync*, so > that hopefully we can reach consensus on first release sync. Also, please > feel free to *raise anything else that you'd like to discuss* in this > thread*.* > > * ## Preview Release* > > In a previous thread [5], Jark proposed to have a preview release before > the formal 2.0 release. The 2.0 release is expected to contain many API > breaking changes. Having a preview release would allow people, especially > partener projects, to adapt to the new APIs early, and provide feedback for > us before we commit to compatibility of these APIs in the formal 2.0 > release. > > The preview release can be lightweight. We don't need to complete all > planned features in it, and can focus only on API breaking changes. > Ideally, all API breaking changes should be done in the preview release. > However, we still allow breaking changes between the preview and formal > releases, in order to fix problems found in feedback on the preview > release. Most API breaking changes should already have been well planned > and partially done in previous release cycles, the remaining tasks are > mainly removing deprecated APIs, making them possible to complete > relatively soon. Moreover, we don't need to spend a lot of effort on > testing and stabilizing the release, because we don't expect people to use > it for production. > > *## Time Plan* > > If the community agrees to have a preview release, we'd propose to have > the following time plan. > - Having a preview release at around the end of September. All foreseeable > API breaking changes for release 2.0 should be included. There will be no > feature freeze, nor comprehensive release testing, for the preview release. > - Feature freeze for the formal 2.0 release at around the end of November. > This gives us roughly 2 months for collecting feedback from the preview > release. > - Formal release at around the end of December, or likely January next > year. > > *## Work Items* > > We have previously collected a list of must-have and nice-to-have work > items [4]. Unfortunately, despite being marked as must-have, some work > items won't make release 2.0, due to e.g. prior deprecation efforts not > completed in previous releases. I think this is because we marked all API > breaking changes as must-have, while some of them don't really have high > priorities. Meantime, as discussed in [5], we won't block new features not > listed in the previous list [4]. We will still collect feature plans for > the 2.0 release cycle, as we did for other recent releases. > > So here's my proposal. > - We will have two lists, for breaking changes and non-breaking changes > respectively. > - For breaking changes, they are expected to be completed in the preview > release, at least the breaking part. Exceptions can be made but would > require case-by-case discussions with the release managers, similar to > making exceptions for feature freeze in previous releases. > - For non-breaking changes, we'll apply the same time-based rules just > like other minor releases, that only features completed by the feature > freeze date will be included. > > If the community agrees, I can update the wiki page, update the existing > lists and start collecting new features for this release cycle. In > addition, I'll go through existing work items, check with the contributors > and remove those that are no longer available. > > > Looking forward to your feedback. > > Best, > > Xintong > > > [1] https://lists.apache.org/thread/b8w5cx0qqbwzzklyn5xxf54vw9ymys1c > > [2] https://calendar.app.google/YaCmuXHGmUbC7w659 > > [3] https://meet.google.com/fre-kcvf-mwt > > [4] https://cwiki.apache.org/confluence/display/FLINK/2.0+Release > > [5] https://lists.apache.org/thread/rz9n4r8cng8j80hx6zwb19xfjft5t75h > >
