Chris Holdgraf

Hmmm - what about a system like: - In `version.json` one of the entries can have a `preferred: true` key/val - If the version of the docs does not match...

yeah - I guess the other approach we could take is to let the `switcher.json` file have two top-level keys: - `config`: "key-val pairs that control various behavior, such as...

I mean, I think that in general having the top-level structure of the JSON file be a `dict` instead of a `list` will make it more extensible/future-proof. Maybe at the...

Could you (or others) share your opinion on what seems like an intuitive and hassle free config structure to trigger other kinds of behavior like "direct people to version X"?...

Hmmm, thinking about this more: I think that the simplest path forward would be to leave the configuration as, is, but introduce two optional keys per entry: - `"preferred": "true"`....

@bryevdv I'm a bit confused - with the current system, you have to manually add new versions to the JSON when a new version is released. It doesn't seem like...

> This seems fragile since it seems like it would be trivially easy to accidentally mark or leave two or three release blocks as preferred unintentionally I wonder if you...

Hmmm ok. So just to confirm, you think that this problem would go away if the configuration could be something like: ```json { "preferred": "

Well in our case we'd check for the `version_match` variable that's defined in `conf.py` and I think the logic would be "is this documentation's `version_match` == `"preferred": ""`? If not,...

Yeah - though now I'm wondering if we should just use DOCUMENTATION_OPTIONS instead. How does that get populated?