> should we let users enable the new uuid ids later when they are sure they > will not downgrade in the future?
I strongly believe new features should be off by default and give a “good enough” grace period before enabling by default (while still offering support to disable). As long as this is disabled by default I am cool with it. > On Oct 26, 2021, at 1:25 PM, Jacek Lewandowski <lewandowski.ja...@gmail.com> > wrote: > > Yes, those explanations sound very reasonable to me as well and I'll push the > implementation soon. > > Thank you guys > > On 2021/10/26 18:21:44, Joshua McKenzie <jmcken...@apache.org> wrote: >> +1 to Benedict's perspective here. Supporting both sstable ID paradigms >> should be relatively trivial and low cost to maintain going forward. >> >> On Tue, Oct 26, 2021 at 7:54 AM bened...@apache.org <bened...@apache.org> >> wrote: >> >>> 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 >>>> >>>> >>> >> > > --------------------------------------------------------------------- > 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
