RFC - O3DE Docs Version Picker/Dropdown Centralization

[GaianHelmers]

Describe the feature you'd like available on the website

I was thinking that perhaps the version picker could be decoupled from the repo versions and held in some sort of "current" location that only needs to update once and have all the previous versions simply pull the list from there.

It would allow for one PR to change the picker list, which would then propagate to all the docs versions.

Proposed implementation

From an immediate glance it would require one last PR wave through all the previous versions to build whatever functionality it would need to draw from a non-local destination.

The new resting place of it would need to remain as a single point of contact, not something that ends up passing through the future versions and breaks back into different "current" locations.

And would ultimately require a refactor to what is being done for that version picker, as the code required to pull it in from somewhere would definitely necessitate different logic.
Of course that would also allow for a redesign over how the picker names, redirects, etc. Which could allow for a much smoother, more intuitive updating process.

Available alternatives

Original Functionality
The current method of updating the version dropdown requires needing to go through every docs version repo and do a manual update to the list and submit a PR that requires approvals and mergers.

It's prone to errors, inconsistencies, and flat out missing repos. And the functionality of the dropdown itself is quite unintuitive.

Generative Local List
A concept from @ShaunaGordon:
"Pull straight from Github and just pull the branches and pay attention to the version/* ones, sorting them by version value, and populating the picker with that. However, I don't know offhand if I can get that information without authentication (and auth via JS kind of defeats security stuff). It's something that was kind of on my mental todo list for when I propose refactoring version management overall."

Supplements

Unfortunately I am not particularly clear on how the website works to use the dropdown listing files, or how one would go about centralizing the picker alone and then drawing it into the docs pages. Certain things would definitely need a refactor.

[ShaunaGordon]

The current dropdown is a Hugo template that's populated at build time by a list in the config file:

[params.docs]
versions = [
  ["24.09", "https://docs.o3de.org"],
  ["development", "https://development--o3deorg.netlify.app"],
  ["23.10", "https://version-2310--o3deorg.netlify.app"],
  ["23.05", "https://version-2305--o3deorg.netlify.app"],
  ["22.10", "https://version-2210--o3deorg.netlify.app"],
  ["22.05", "https://version-2205--o3deorg.netlify.app"]
]

This list has to be updated on every version release, not just on the branch to be released, but on all other version branches in the list. Once merged, it prompts the system to rebuild all of the branches, which may use paid CI/CD resources, depending on how it's set up. Thankfully, Hugo is fast, so the Hugo build step takes only a few seconds, but it still requires spinning up images, installed dependencies, and tearing it all down afterward, which all takes time. Multiply that by a growing number of versions and it become plain to see why it's prudent to come up with some better solutions sooner rather than later.

[ShaunaGordon]

Alright, so I just looked through the Github docs and toyed around with the API, and confirmed that I can get the branches from the o3de.org repo without authentication. This makes the idea of querying the repo branches a whole heck of a lot easier. The only snag is that there's no indication for what the current version is, since that's just main.

Alternatively, we could start tagging versions, then key off of those. The tag only needs to be added at initial release, since it's just to get the Netlify address and display string. The rest of the process for publishing would remain the same.