What does this mean for the Trie sstable format? Would it perhaps make sense to version the sstable upgrader (and future downgrader) based on the highest version they understand? for example sstableupgrader version N will handle the n? versions so it can upgrade from m? while sstabledowngrader version N can downgrade from m? to n<limit>, where <limit> is the lower limit that downgrader can write. In this way users trying to upgrade from out of support major releases can use multiple upgraders and downgraders to move forward and/or recover from a failed upgrade.
In this case the sstablesupgrader and sstablesdowngrader should report any tables that it can not handle and not execute the upgrade/downgrade. On Fri, Jan 13, 2023 at 1:17 PM Jacek Lewandowski < lewandowski.ja...@gmail.com> wrote: > Hi, > > I'd like to bring that topic to your attention. I think that we should > think about allowing users to downgrade under certain conditions. For > example, always allow for downgrading to any previous minor release. > > Clear rules should make users feel safer when upgrading and perhaps > encourage trying Cassandra at all. > > One of the things related to that is sstable format version. It consists > of major and minor components and is incremented independently from > Cassandra releases. One rule here is that a Cassandra release producing > sstables at version XY should be able to read any sstable with version > (X-1)* and X* (which means that all the minor future versions X. Perhaps we > could make some commitment to change major sstable format only with new > major release? > > What do you think? > > Thanks > - - -- --- ----- -------- ------------- > Jacek Lewandowski >
