Add release guide, and deploy docs on release

[tsmbland]

Description

Adds a developer guide for making a release, based on the list given by Alex in #1264. I haven't done this yet, so will follow this guide when making the next release. Hopefully everything works!

I've also added a note about checking the muse2_data_analysis repo and creating a matching release for that.

The only other change is to change the documentation workflow so it runs on release, otherwise we'd have to trigger it manually to get a documentation page for the new release.

Fixes #1264

Type of change

• Bug fix (non-breaking change to fix an issue)
• New feature (non-breaking change to add functionality)
• Refactoring (non-breaking, non-functional change to improve maintainability)
• Optimization (non-breaking change to speed up the code)
• Breaking change (whatever its nature)
• Documentation (improve or add documentation)

Key checklist

• All tests pass: $ cargo test
• The documentation builds and looks OK: $ cargo doc
• Update release notes for the latest release if this PR adds a new feature or fixes a bug
  present in the previous release

Further checks

• Code is commented, particularly in hard-to-understand areas
• Tests added that prove fix is effective or that feature works

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.30%. Comparing base (b36dd9a) to head (17fc384).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1507   +/-   ##
=======================================
  Coverage   90.30%   90.30%           
=======================================
  Files          60       60           
  Lines        8658     8658           
  Branches     8658     8658           
=======================================
  Hits         7819     7819           
  Misses        525      525           
  Partials      314      314           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Pull request overview

This PR adds a developer-facing release guide to document the manual steps involved in cutting a new MUSE2 release (including synchronising a matching release in muse2_data_analysis) and updates the docs deployment workflow so documentation is automatically rebuilt and published when a GitHub Release is published.

Changes:

• Add a “Making a release” page under the Developer Guide with a step-by-step checklist.
• Link the new release guide from the mdBook summary.
• Trigger the GitHub Pages docs deployment workflow on release.published in addition to push and manual dispatch.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
docs/SUMMARY.md	Adds the new “Making a release” page to the Developer Guide navigation.
docs/developer_guide/release.md	Introduces a release process guide covering release notes, version metadata, publishing, and syncing muse2_data_analysis.
.github/workflows/deploy-docs.yml	Runs docs build/deploy when a GitHub Release is published so release docs get deployed without a manual trigger.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[dalonsoa]

It looks good, but I've a few comments/questions.

[dalonsoa]

Suggested change

	Before preparing the release, manually run the [Test with MUSE2 workflow] on the `main` branch of
	the [muse2_data_analysis repository] and check that all jobs pass. This workflow tests the analysis
	repository's `main` branch against MUSE2's `main` branch.
	Before preparing the release, manually run the [Test with MUSE2 workflow] on the `main` branch of
	the [muse2_data_analysis repository] and check that all jobs pass. This workflow tests the analysis
	repository's `main` branch against MUSE2's `main` branch. If it **does not pass**, identify and fix the errors there before proceeding with the release.

[dalonsoa]

What does complete and correct means in this context? It is not that there should be an entry per PR, regardless of nature (some are just typos or refactoring without functional changes), right?

[tsmbland]

Good point. It should be more curated and targeted for users than just a list of PRs. I'll update this with more specific instructions.

[dalonsoa]

I cannot see any developer instructions in the file. Are they somewhere else?

[tsmbland]

In upcoming.md there's a comment at the top with some instructions for developers. This was just to say that after copying and renaming this file, you should delete that section. That said, these instructions are now repeated in the release guide, so we can probably remove this.

[dalonsoa]

Ah, ok. It is hidden, so I didn't see it in the rendered md view.