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
Symbol | Meaning |
---|---|
Must-have Item | |
Nice-to-have Item |
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 | ||||
| Remove deprecated APIs - all Scala APIs | |||
Remove deprecated APIs - SourceFunction / SinkFunction / TableSource / TableSink | ||||
Remove deprecated APIs - Legacy SQL function stack and operators | ||||
| 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.
|