Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-04-13 14:44:10 +02:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Updates to release process (#2289)

Browse source 
Some clarifications to the release process doc, particularly in view of #2275.
This commit is contained in:
Richard van der Hoff 2026-01-06 17:05:59 +00:00 committed by GitHub
parent fb2221aad7
commit f2b68c7163
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
2 changed files with 16 additions and 15 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
changelogs/internal/newsfragments/2289.clarification Normal file
View file

@ -0,0 +1 @@
Updates to the release documentation.

30
meta/releasing.md
View file

@ -50,11 +50,6 @@ First, can we even release the spec? This stage is mostly preparation work neede
to ensure a consistent and reliable specification. to ensure a consistent and reliable specification.
1. Ensure `main` is committed with all the spec changes you expect to be there. 1. Ensure `main` is committed with all the spec changes you expect to be there.
2. Review the changelog to look for typos, wording inconsistencies, or lines which
can be merged. For example, "Fix typos" and "Fix spelling" can be condensed to
"Fix various typos throughout the specification".
3. Do a quick skim to ensure changelogs reference the MSCs which brought the changes
in. They should be linked to the GitHub MSC PR (not the markdown document).
## The release ## The release
@ -79,20 +74,24 @@ release.
2. Run `./scripts/generate-changelog.sh v1.2` (using the correct version number). 2. Run `./scripts/generate-changelog.sh v1.2` (using the correct version number).
The script will use the current date. If that date is wrong, correct the document The script will use the current date. If that date is wrong, correct the document
by using the same `YYYY-MM-DD` date format. by using the same `YYYY-MM-DD` date format.
3. Commit the result. 3. Review the changelog to look for typos, wording inconsistencies, or lines which
can be merged. For example, "Fix typos" and "Fix spelling" can be condensed to
"Fix various typos throughout the specification".
4. Do a quick skim to ensure changelogs reference the MSCs which brought the changes
in. They should be linked to the GitHub MSC PR (not the markdown document).
5. Commit the result.
6. Now is a good time to have someone else review the changelog.
5. Tag the branch with the spec release with a format of `v1.2` (if releasing Matrix 1.2). 5. Tag the branch with the spec release with a format of `v1.2` (if releasing Matrix 1.2).
6. Push the release branch and the tag. 6. Push the release branch and the tag.
7. GitHub Actions will run its build steps. Wait until these are successful. If fixes 7. GitHub Actions will run its build steps. Wait until these are successful. If fixes
need to be made to repair the pipeline or spec build, delete and re-tag the release. need to be made to repair the pipeline or spec build, delete and re-tag the release.
You may need to fix up the changelog file by hand in this case. You may need to fix up the changelog file by hand in this case.
8. Check out and fast-forward `main` to the release branch. 8. GitHub Actions should have drafted a release based on the new tag. Find it
9. Create a new release on GitHub from the newly created tag. at https://github.com/matrix-org/matrix-spec/releases.
* The title should be just "v1.2" (for example). 1. Double-check the generated release notes, and check that `spec-artifact.zip` and
* The description should be a copy/paste of the changelog. The generated changelog `spec-historical-artifact.zip` are both attached to the draft release.
will be at `content/changelog/v1.2.md` - copy/paste verbatim. 2. Publish the draft release.
* Upload the artifacts of the GitHub Actions build for the release to the GitHub 9. Check out and fast-forward `main` to the release branch.
release as artifacts themselves. This should be the tarball that will be deployed
to spec.matrix.org.
10. Commit a reversion to `params.version` of `./config/_default/hugo.toml` on `main`: 10. Commit a reversion to `params.version` of `./config/_default/hugo.toml` on `main`:
```toml ```toml
[params.version] [params.version]
@ -103,7 +102,8 @@ release.
``` ```
11. Push pending commits and ensure the unstable spec updates accordingly from the 11. Push pending commits and ensure the unstable spec updates accordingly from the
GitHub Actions pipeline. GitHub Actions pipeline.
12. Deploy the release on the webserver. See internal wiki. 12. Deploy the release on the webserver. See "Spec release process" in the
internal handbook.
## Patching a release ## Patching a release