Hi, we currently track deprecation of features largely through TODOs in the source code. Here we typically write down a release at which a deprecated feature should be removed.
I believe this is less than optimal since * it is hard for users of our APIs to track when a deprecated feature is actually removed, * it seems to encourage versioning-related discussions to happen in potentially low-visibility review requests instead of JIRA tickets, * this approach can lead to wrong or misleading information in the code as our versioning policies evolve and mature, and * poor trackability of outstanding deprecations leads to lots of missed opportunities to remove features already out of their deprecation cycle as we prepare releases. I would like to propose to use JIRA for tracking deprecations instead. A possible approach would be: 1) When a feature becomes deprecated, a JIRA ticket is created for its removal. The ticket can be referenced in the source code. 2) The ticket should be tagged with e.g. `deprecation`, and optimally link back to the ticket triggering the deprecation. 3) A target version is set in collaboration with maintainers of the versioning policy. 4) The release process is updated to involve bumping target versions of unfixed deprecation tickets to the following version. I believe with this we would be able to better keep track and ultimately fix tech debt, as well as better improve communicating breaking to users. Any thoughts? Cheers, Benjamin
