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
