DOC: Add version switcher to documentation

[AbhiRKeesara]

PR summary

Closes #78

What problem does this PR solve?
The documentation currently has no way for users to switch between versions. Users visiting the homepage see a static landing page rather than being directed to the latest stable docs.

Why are you interested in working on this PR?
I'm participating in the NumFOCUS Sustaining Open Source Series program and picked this issue to help improve the documentation experience.

Changes:

• Add versions.json with entries for dev and 1.1.0 (stable)
• Configure html_theme_options in conf.py for the version switcher (modeled after NumPy's pattern)
• Add GitHub icon link to navbar
• Update copyright year to dynamic range (2005-current) per LICENSE.txt
• Extend publish_docs_to_pages.yml workflow to:
  • Build versioned docs on release tags (v*)
  • Auto-update versions.json when new releases are published
  • Deploy dev docs to /dev/ and releases to /version/X.Y.Z/
  • Update latest symlink to point to newest release
  • Add root index.html redirect to /latest/ (per maintainer suggestion in DOC: Documentation should be available for different versions #78)
• Update RELEASE.md to reflect automated docs deployment

Testing:

• Built docs locally with make html and verified the version switcher appears in the navbar
• Tested dropdown population using the local versions.json
• Verified GitHub icon displays next to the version selector
• Validated workflow YAML syntax with Python yaml parser

Notes:

• The latest symlink and root redirect will take effect on the first release tag push after this is merged
• Future releases will automatically be added to versions.json by the workflow

AI Disclosure

Used Kiro (AI assistant) for implementation guidance, workflow YAML generation, and drafting this description. Changes were verified locally through docs builds and manual testing.

[mattip]

Cool. Creating the index.html is a once-off, no need to do it repetitively in CI. Also creating the version json need only happen on release, not on dev builds.

[AbhiRKeesara]

@mattip - Thanks for the feedback! I'll remove the index.html creation from CI. After this PR merges, the redirect can be added once manually to gh-pages.

Regarding versions.json: the workflow currently only updates it on release builds (inside the if [ "$IS_RELEASE" = "true" ] block), not on dev builds. Am I reading your comment incorrectly, or is there something else you'd like changed there?

[mattip]

Regarding versions.json: the workflow currently only updates it on release builds

My mistake.

After this PR merges, the redirect can be added once manually to gh-pages

Why not change index.html as part of this PR?

[AbhiRKeesara]

Thanks for confirming on versions.json.

For index.html, do you mean:

1. Add a conditional check so the workflow creates it only if it doesn't exist (one-time on first release), or
2. Open a separate PR targeting gh-pages to add it directly?

[mattip]

Ahh, I see. That file only lives on gh-pages, so yes, a separate PR is needed.

[AbhiRKeesara]

@mattip Updated the workflow to remove the index.html creation. Opened a separate PR targeting gh-pages for the redirect: #154

[mattip]

LGTM now

[stefanv]

I think this PR can be simplified significantly. We can unconditionally generate the list of versions on each docs build without penalty. The docs repo, into which we're pushing, contains the list of versions already, and the latest version is stable.

I am on a phone now, but can review a bit more carefully later.

If this feels urgent, go ahead and merge then I will refactor. Otherwise polishing it up a bit will, I think, make the flow easier to follow.

[AbhiRKeesara]

@stefanv - Thanks for the feedback! No urgency on my end. Happy to wait for your detailed review and simplify based on your suggestions. The cleaner the final implementation, the better.