Do I understand it correctly that this is basically the case of "deprecated on introduction" as we know that it will not be necessary the very next version?
I think that not everybody is upgrading from version to version as they appear. If somebody upgrades from 4.0 to 5.1 (which we seem to support) (1) and you would have introduced the deprecation in 4.0 with intention to remove it in 5.0 and somebody jumps to 5.1 straight away, is not that a problem? Because they have not made the move via 5.0 where you upgrade logic was triggered. (1) https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/upgrade/UpgradeTestBase.java#L97-L108 ________________________________________ From: Claude Warren, Jr via dev <dev@cassandra.apache.org> Sent: Tuesday, October 31, 2023 10:57 To: dev Cc: Claude Warren, Jr Subject: Immediately Deprecated Code NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe. I was thinking about code that is used to migrate from one version to another. For example the code that rewrote the order of the hash values used for Bloom filters. That code was necessary for the version it was coded in. But the next version does not need that code because the next version is not going to read the data from 2 versions prior to itself. So the code could be removed for verson+1. So, would it have made sense to annotate those methods (and variables) as deprecated since the version they were written in so the methods/variables can be removed in the next version? If so, what I propose is that all transitional methods and variable be marked as deprecated with the version in which they were introduced.
