Good point. When I was thinking about this originally I did realize that the deprecated tag would need a since = v+1 but I neglected to note that in my original post. So in your example the code would be maked as deprecated since v5.0 even though the code base it is being written in is 4.0. Thus the code would not be a candidate for removal until 6.0 I think that this make it easier to remember all those bits that can be deleted later.
On Tue, Oct 31, 2023 at 11:57 AM Miklosovic, Stefan via dev < dev@cassandra.apache.org> wrote: > 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. > >
