In your example 5.1 can read 4.x because 4.0 (?) is the earliest version that 5.x supports. I don't think you can upgrade directly from 3.x to 5.x without an intermediate stop at some version of 4.x can you? So when we get to 6.x we won't need the 4 -> 5 conversion code because 6 will only support reading from 5. If I am incorrect and we expect a version to be able to read 2 major versions back then indeed the deprecated since would be 2 major versions ahead of the version when the code was written.
On Tue, Oct 31, 2023 at 2:40 PM Andrew Weaver <andrewjwea...@gmail.com> wrote: > 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 >
