...
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 | ||||||||||||
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) |