Update references to settings.json to reflect new name

[chelnak]

Description

As part of the settings management project, settings.json has been renamed to settings-store.json.

This change updates the public docs so that they reflect the new name.

Related issues or tickets

https://docker.atlassian.net/browse/DS-1506

Reviews

• [x] Technical review @ebriney @aiordache
• [x] Editorial review @aevesdocker
• [x] Product review @KatTomrushka

[netlify[bot]]

✅ Deploy Preview for docsdocker ready!

Name	Link
🔨 Latest commit	5093f01063989cca12ba5195298418051b08c63b
🔍 Latest deploy log	https://app.netlify.com/sites/docsdocker/deploys/6718c1f25b87b100085aab61
😎 Deploy Preview	https://deploy-preview-21003--docsdocker.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[thaJeztah]

Curious (I didn't know this file was renamed); do newer versions accept both old and new location? Wondering if changing this filename will be disruptive in situations where these files are to be managed, and not all users having the "latest" version installed.

[laurazard]

Yeah, I'm sure this has been discussed at length but I'm wondering about the pros and cons of having to reference both versions in any documentation making a reference to settings.json for the next few years 😅 .

[djs55]

Re: the old vs new settings file: the new DD will upgrade the existing settings.json to settings-store.json (with the new format) but leave the old file in place in case of downgrade.

The official supported way to adjust the settings is via the admin-settings.json (which has a stable format) and the UI. Instructions to edit the settings.json are a kind of "escape hatch" for working around issues (IMO). Personally I would update the docs to the new format (as here + mention DD 4.35+) and omit the instructions for the old format, since people should upgrade anyway (for e.g. security fixes)

[chelnak]

The official supported way to adjust the settings is via the admin-settings.json (which has a stable format) and the UI. Instructions to edit the settings.json are a kind of "escape hatch" for working around issues (IMO). Personally I would update the docs to the new format (as here + mention DD 4.35+) and omit the instructions for the old format, since people should upgrade anyway (for e.g. security fixes)

You have a good point here @djs55

@aevesdocker What do you think?

[laurazard]

and omit the instructions for the old format, since people should upgrade anyway (for e.g. security fixes)

It would really suck if as a user I was on an older version of DD and went looking for something in the docs and only found references to a file that doesn't exist on my machine, and even if I created that file it wouldn't do anything. At the very least all of those should have a link/tooltip that a user can click on explaining that this file moved/was renamed.

[chelnak]

as a side thought it would be cool at some point to have a version selector in the docs. Pretty sure that comes with its own challenges .

There was a comment about ux for previous version info here that could be nice.

[ebriney]

I'm more in favor of dropping legacy (remove all refs to setting.json). As said above, it has never been considered as stable, we changed it in the past already (we have used datakit, plist). And we should use PascalCase for settings snippet in the docs. At least it is justifying why we changed the filename.

[laurazard]

It's never been considered stable but it has been documented. Is it that much of a chore to create a little note next release stating "renamed/moved .../settings.json to ...settings-store.json" and link it in these places for a few months/versions, considering that it can't hurt and might help some user? I'd like to think we'd prefer to be more developer-obsessed here and do what we can to create as little confusion as possible

[chelnak]

Hey everyone. This has generated some great discussion, thanks for your feedback.

I'll talk it through with @aevesdocker this week and get the PR updated.