Hi Timo, Thanks for starting this discussion. I'm not sure how we should approach this topic and what should be our final recommendation, but definitely clearing up a couple of things would be helpful.
For starters, I agree it would be good to have some more information, besides just "@Deprecated" annotations. Is it possible to extend annotations with informations like: - from which version was it deprecated - when is it planned to be removed (we could always mark `2.0` as "never" ;) ) - add maybe some pre/post release step of verifying that removal has actually happened? ? On the other hand, I think it's very important to maintain backward compatibility with Flink as much as possible. As a developer I don't like dealing with this, but as a user I hate dealing with incompatible upgrades even more. So all in all, I would be in favour of putting more effort not in deprecating and removing APIs, but making sure that they are stable. Stephan Ewan also raised a point sometime ago, that in the recent past, we developed a habit of marking everything as `@Experimental` or `@PublicEvolving` and leaving it as that forever. Maybe we should also include deadlines (2 releases since introduction?) for changing `@Experimental`/`@PublicEvolving` into `@Public` in this kind of guidelines/automated checks? Piotrek pt., 15 sty 2021 o 13:56 Timo Walther <twal...@apache.org> napisał(a): > 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 > > > > > >
