For online upgrades we support skipping majors so long as the majors are adjacent. That is, any 4.x.z to any 5.x.z ( Is it recommended that you always first patch upgrade the .z to the latest before the major upgrade. )
For offline upgrades, we are aiming to maintain all compatibility. Take care when removing code, there are various (serdes) classes that look like they are for other components but are also used in the storage engine. On Tue, 31 Oct 2023 at 18:42, Claude Warren, Jr via dev < dev@cassandra.apache.org> wrote: > 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 >> >
