Hi everyone,
great to see all these responses. I'm happy to drive this effort. I will
try to summarize this discussion and look into how other projects are
handling this topic. A might need a couple days more for this. After
that we can discuss how we would like our guidlines to look like.
Thank you for starting this discussion Timo!
Maybe we should draft a Wiki page outlining our deprecation and removal
policies for legacy code in Flink. We'll need such a document anyways, and
summarizing the consensus from this discussion into a document would allow
us to move forward with this
>
> I would prefer not to rely on the Jira for marking when something is
> supposed to be deleted. If `@Deprecated(since, planned_to_remove_on)` would
> have two obligatory parameters, there would be no way to "forget" about
> marking it and it would be also self documenting (I don't imagine users
Hi,
I think having two Deprecated annotations (Flink and Java) may be confusing.
One alternative is to combine standard annotation with mandatory Javadocs
tags (checked with checkstyle).
And starting from Java 9 it has "since" and "forRemoval" arguments.
Regards,
Roman
On Wed, Jan 20, 2021 at
Hi,
I would prefer not to rely on the Jira for marking when something is
supposed to be deleted. If `@Deprecated(since, planned_to_remove_on)` would
have two obligatory parameters, there would be no way to "forget" about
marking it and it would be also self documenting (I don't imagine users
Thanks Timo for opening this discussion.
+1 I like the idea of adding a deprecation deadline and/or information when
the
functionality was deprecated. It looks like this is already done in the
PyFlink code.
Creating a JIRA issue for removing the functionality, as Till suggested,
might help to
Thanks a lot for starting this discussion Timo. I like the idea of setting
more explicit guidelines for deprecating functionality.
I really like the idea of adding with the @Deprecated annotation since when
the function is deprecated. Based on that one can simply search for
features which should
Hi,
Very thanks for @Timo to initiate the discussion!
I would also +1 for providing some informations to users via annotations
or documents in advanced to not suprise users before we actually remove the
legacy code.
If we finally decide to change one functionality that user could sense,
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
