The user will be able to test the new feature in a testing environment
and not push the changes to their production environment if they are not
satisfied.
On 26/10/2021 12:00, Jacek Lewandowski wrote:
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
