Hi everyone,
I would like to start a discussion how we treat deprecated and legacy
code in Flink in the future. During the last years, our code base has
grown quite a bit and a couple of interfaces and components have been
reworked on the way.
I'm sure each component has a few legacy parts that are waiting for
removal. Apart from keeping outdated API around for a couple of releases
until users have updated their code, it is also often easier to just put
a @Deprecation annotation and postpone the actual change.
When looking at the current code, we have duplicated SQL planners,
duplicated APIs (DataSet/DataStream), duplicated source/sink interfaces,
outdated connectors (Elasticsearch 5?) and dependencies (Scala 2.11?).
I'm wondering whether we should come up with some legacy/deprecation
guidelines for the future.
Some examples:
- I could imagine new Flink-specific annotations for documenting (in
code) in which version an interface was deprecated and when the planned
removal should take place.
- Or guidelines that we drop a connector when the external project does
not maintain the version for 6 months etc.
Plannable removal dates should also help users to not be surprised when
a connector or Scala version is not supported anymore.
What do you think? I'm very happy to hear more opinions.
Regards,
Timo
