I think it is probably acceptable to prevent downgrades once a new feature is enabled, as the exposure risk is limited to that one feature. The user can test the new version to ensure everything else works satisfactorily before committing to this one feature.
A downgrade tool would also be possible to produce, but probably the additional utility is limited. I think this particular feature is probably easy enough to maintain as permanently optional, simply maintaining two system tables: one for the old generation format, one for the new. So long as the user doesn’t use the new format, it remains forever downgradeable. Though perhaps one day we may want to force users to migrate, I don’t think there’s any rush, and the important thing to avoid is providing users no version buffer to escape new bugs – if a major version later we force upgrade, then they have a whole range of major versions to downgrade to that still support this feature (but perhaps avoid some other new issue) From: Jacek Lewandowski <lewandowski.ja...@gmail.com> Date: Tuesday, 26 October 2021 at 12:01 To: dev@cassandra.apache.org <dev@cassandra.apache.org> Subject: Re: [DISCUSS] How to implement backward compatibility (CASSANDRA-17048) Though, the user is unable to test the new feature without enabling it. And when it is enabled, the user is unable to revert it. - - -- --- ----- -------- ------------- Jacek Lewandowski On Tue, Oct 26, 2021 at 12:54 PM Bowen Song <bo...@bso.ng.invalid> wrote: > Personally, I would prefer a transition period in which the new feature > is not enabled by default. This not only makes version upgrading easier, > it also allows the user to stay on the old behaviour if they experience > any issue with the new feature (e.g.: bugs in the new feature, or edge > use cases / 3rd party tools depending on the old behaviour) until the > issue is resolved. > > On 26/10/2021 10:21, Jacek Lewandowski wrote: > > Hi, > > > > In short, we are discussing UUID based sstable generation identifiers in > https://issues.apache.org/jira/browse/CASSANDRA-17048. > > > > The question which somehow hold us is support for downgrading. Long > story short, when we generate new sstables with uuid based ids, they are > not readable by older C* versions. > > > > 1. should we implement a downgrade tool? (it may be quite complex) > > 2. should we let users enable the new uuid ids later when they are sure > they will not downgrade in the future? > > > > Thanks, > > Jacek > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
