Skipping versions on upgrade is absolutely something that happens in the real world. This is particularly highlighted by the discussion around 5.0/5.1 that's been happening - 5.0 has been described as a potential "ghost version" which I completely understand.
Getting rid of some of the old cruft that seems unnecessary (and strictly speaking is unnecessary) is not without its downsides. In this case, that cruft improves the user experience. On Tue, Oct 31, 2023 at 5:56 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. > > -- Andrew Weaver
