Remove mention of 'declarative' schema changer' #19443
Conversation
Fixes DOC-8693 Summary: - Remove mentions of "declarative schema changer" (DSC) for the following reasons: - 1. It is enabled by default, and 99% of users will never change the relevant setting or even need to know what that is. - 2. Its existence is an internal implementation detail that is fine for internal TSE runbooks to refer to, but should not really be in customer-facing docs since "it uses two different implementations on the inside, one of which we're migrating away from" should not be a thing that matters to 99% of users unless there is a specific problem they are working with TSE to solve.
Files changed:
|
✅ Deploy Preview for cockroachdb-api-docs canceled.
|
✅ Deploy Preview for cockroachdb-interactivetutorials-docs canceled.
|
|
this PR comes out of a convo with Dikshant re: us maintaining lists of "which statement is done by the DSC" is not really helpful for users and is more of an internal detail that is leaking out IMO the PR only removes 'declarative schema changer' stuff from prose, it does not remove the documentation for the variable that controls on/off it also removes the whole "list of which statements" which, as a user, it's not clear what that list is for or why i should care other than "it's magically better somehow" which feels very internal to the team/CRL support, not user-facing also it only changes v25.1 for our review, once we're happy with this change i will backport this change to earlier versions. If you have opinions about which earlier versions we should/should not make this change to, i'm def open to that. i was thinking v23.1+ but please let me know |
✅ Netlify Preview
To edit notification comments on pull requests, go to your Netlify site configuration. |
Fixes DOC-8693
Summary:
Remove mentions of "declarative schema changer" (DSC) for the following reasons:
It is enabled by default, and 99% of users will never change the relevant setting or even need to know what that is.
Its existence is an internal implementation detail that is fine for internal TSE runbooks to refer to, but should not really be in customer-facing docs since "it uses two different implementations on the inside, one of which we're migrating away from" should not be a thing that matters to 99% of users unless there is a specific problem they are working with TSE to solve.