Add release guide, and deploy docs on release - #1507
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1507 +/- ##
=======================================
Coverage 90.30% 90.31%
=======================================
Files 60 60
Lines 8658 8663 +5
Branches 8658 8663 +5
=======================================
+ Hits 7819 7824 +5
Misses 525 525
Partials 314 314 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
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.publishedin addition topushand 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
left a comment
dalonsoa
left a comment
There was a problem hiding this comment.
It looks good, but I've a few comments/questions.
| releases from the Python-based [MUSE_OS]. The second digit represents major changes, while the third | ||
| digit represents minor changes. This is a looser versioning scheme than Semantic Versioning, where | ||
| "major" and "minor" have stricter definitions. |
There was a problem hiding this comment.
In that case, is it worth describing what constitutes a major or minor change?
There was a problem hiding this comment.
Maybe, but we don't really have a proper set of rules for this yet. In MUSE1 I've just used my own subjective judgement each time. I didn't even want to enforce a rule around breaking/non-breaking changes, because some technically breaking changes could be very minor and require minimal/no effort to address, so wouldn't necessarily warrant a major update.
AdrianDAlessandro
left a comment
AdrianDAlessandro
left a comment
There was a problem hiding this comment.
Very clear, process appears complete and makes sense
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_analysisrepo 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
Key checklist
$ cargo test$ cargo docpresent in the previous release
Further checks