> 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.Bti
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
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
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
suppor
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
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
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 supp
