Release Managers

Jiangjie Qin Xintong Song Martijn Visser Jark Wu 

Timeline

• A rough target is to ship the 2.0 release around mid 2024
• In short term, we are trying to finalize the work item list by end of June 2023

Work Items

Priority

• Must-have Items
  • Things that must be done in release 2.0.
  • Typically, this should include only API breaking changes.
  • If not finished, the release will be blocked.
• Nice-to-have Items
  • Everything else that is planned for the 2.0 release.
  • If not finished, the release will not be blocked.

If there's a resource conflict (e.g., requiring efforts from the same group of people, interference due to actively working on the same pieces of codes, etc.), must-have items should be prioritized over nice-to-have items

Legend

List

Please fill the chart with your proposals by June 15, 2023. After June 15, we'll organize further discussions to decide a minimum set of must-have items with the community.

Once decided, modification of the list would require community decision. Please reach out to the release managers and do not modify the list directly.

Item	Priority	Responsible Contributor	Available Reviewer / Committer	Description
				Remove deprecated APIs - DataSet API
Unable to render Jira issues macro, execution error.				Remove deprecated APIs - all Scala APIs
				Remove deprecated APIs - SourceFunction / SinkFunction / TableSource / TableSink
				Remove deprecated APIs - Legacy SQL function stack and operators
Unable to render Jira issues macro, execution error.				Add support for Java 17 and make this the default.  If needed, drop support for Java 8 and/or 11. Nice-to-have: also add support for Java 21
				Introduce a clean configuration layer. Some things to consider are that all configuration should be expressible via string key-value pairs and use the ConfigOption stack plus removing ExecutionConfig, CheckpointConfig and all member variables of StreamExecutionEnvironment.
				Have a MVP for a ProcessFunction 2.0: a new generic operator that is the only operator that DataStream API users should need to use for building their Flink application, without dependencies on internal implementations and/or 3rd party dependencies.
				All user APIs should be in a separate module, to avoid and prevent the need to rely on internals. StreamOperator should not be a PublicEvolving API, but an Internal only.
				Eager state declaration. This is basically a restart of discussion around FLIP-22: Eager State Declaration.
				Review and refactor the REST API (Clarify the capability guarantees and modification process, revisit existing REST API and improve/remove incorrect interfaces, unify conventions for naming fields, passing parameters and HTTP methods)
				Review and refactor the metrics implementation (separate interfaces for reading and writing, revisit and improve/remove incorrect metrics)
				Disaggregated State Backend/Management for large states in the cloud native era. Support State Sharing and Querying Support fast recoverying/rescaling