Re: Immediately Deprecated Code
> My thought was that we have code that is intended to be used for a > specific time frame. > With your example of bloom filters, if that's on-disk then it is not to be removed. Specifically, code that is used in relation to a sstable format still listed in BigFormat.BigVersion (or BtiFormat.BtiVersion) must be kept. And there are no plans to remove it. See CASSANDRA-18312 There's been some deprecated since annotations added recently that imply a version of Cassandra is using a specific sstable format version. This is no longer true (see the storage_compatibility_mode yaml option). We are to consider past sstable formats are still in use in newer clusters. Though, the introduction of the option bound the lowest format version to 'nb' (see CASSANDRA-14227).
Re: Immediately Deprecated Code
My thought was that we have code that is intended to be used for a specific time frame. We should clean up the code base when that code is no longer used. But we don't have any good way to track that. This proposal was an attempt to provide signposts for removing such code. On Tue, Oct 31, 2023 at 6:56 PM Mick Semb Wever wrote: > > 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 >> 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 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 >>> >>
Re: Immediately Deprecated Code
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 > 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 >>> 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 >> >
Re: Immediately Deprecated Code
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 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 >> 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 >
Re: Immediately Deprecated Code
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 > 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
Re: Immediately Deprecated Code
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 > 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. > >
Re: Immediately Deprecated Code
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 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.
