Hi devs, As the release 2.0 must-have items being voted and approved, the release managers recently had another discussion on how to move forward. Here's the summary.
## Follow-up of previous discussions - As a follow-up of deciding the must-have items [1], Martijn will help draft an announcement to notify users about the planned breaking changes in release 2.0. This is because a) the previous discussion only happened in dev@ML and it's important to also try to reach out to the users, and b) some breaking changes such as dropping Java8 support cannot be noticed by annotations. It is also helpful for collecting early feedback from users. The announcement should make it clear that the plan may change in future. - Becket will help look into approaches for enforcing the API promotion [2] and deprecation [3] processes. - Jark will keep driving and trying to finalize the project roadmap discussion [4]. ## 2.0 Timeline and branch management - We propose targeting a 1.19 -> 1.20 -> 2.0 release sequence, with a normal 4-5 months release cycle, which means shipping the 2.0 release around the end of 2024. Please notice that this is just a best estimation at the moment, which can be changed in future if needed. By the time 1.20 is released, we will make a final decision on whether to work on a 1.21 release or not. - This means, if not further extended, Public APIs need to be deprecated in 1.19 and PublicEvolving APIs in 1.20 in order to be removed in 2.0. *This does not mean developers need to rush in order to get the changes into corresponding versions.* We'd like to deliver the 2.0 release within 2024, but it must not come at the price of compromising the quality. If you see any risk that the planned work items may not be completed in time, please try to reach out to the release managers early. - We are planning to cut the 2.0 branch out of the master branch, right after cutting the 1.20 (say if it's the last 1.x version) branch, or slightly before that, in order to minimize the period that developers need to commit codes into multiple branches. The above have been updated to the wiki page [1]. ## Tracking the 2.0 work items - Regular release sync: We propose to share the same time slot of minor release syncs at the moment, rather than setting up separate syncs. Because we'd expect many 2.0 related items to overlap with the 1.19 / 1.20 work items, and there are unlikely many topics to discuss other than these work items in the early time of preparing 2.0. - We'd like to introduce a label "2.0-related" for JIRA tickets that are planned for the 2.0 release or block other tickets that are planned for the 2.0 release. This helps identify the 2.0 related ones when tracking the issues of 1.19 / 1.20 minor releases. We'd like to ask contributors / reviewers to mark the *relevant JIRA tickets with the "2.0-related" label*. - We'd like to ask the 2.0 work item contributors / reviewers to *provide estimated time / version for the following milestones* of the effort. Please fill them in wiki[1] by the *end of August*. You may check "Introduce a MVP for a new ProcessFunction API" for example. - Design ready - Replacing API (if any) functionality ready. - Replacing API (if any) marked as stable. - Here "stable" means reaching the same stability as the API it tries to replace. I.e., for replacing a @Public API the new API should also be @Public, and for replacing a @PublicEvolving API the new API should also be (at least) @PublicEvolving. - Old API (if any) deprecated. - Old API (if any) removed. - We'd like to ask the contributors / reviewers of *work items whose priority is "TBD"* to look into the items and try to *provide the priority *by the *end of August*. If the item turns out should be a must-have items, we may update the list with another vote. ## Looking for volunteer There are still many issues that do not have contributors / reviewers. *We are looking for volunteers for these unassigned work items*, especially for the TBD ones. If you're willing to contribute, please fill your name in the wiki [1]. Feel free to reach out to the release managers if you need more information. Best, Xintong (on behalf of the release managers) [1] https://cwiki.apache.org/confluence/display/FLINK/2.0+Release [2] https://cwiki.apache.org/confluence/display/FLINK/FLIP-197%3A+API+stability+graduation+process [3] https://cwiki.apache.org/confluence/display/FLINK/FLIP-321%3A+Introduce+an+API+deprecation+process [4] https://lists.apache.org/thread/szdr4ngrfcmo7zko4917393zbqhgw0v5