Generate unstable changelogs using towncrier (#1340)

Replace the current stack of hugo templates with a towncrier invocation. The main advantage of this is that it means that the "Changes since last release" section is consistent with the changelogs for the actual releases.

This also changes the release process so that the changelog is generated before tagging, which means that the thing tagged v1.5 is actually the v1.5 spec.

Fixes #908.
This commit is contained in:
Richard van der Hoff 2022-11-15 23:26:55 +00:00 committed by GitHub
parent 678f8b96f0
commit 08fde5f257
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
13 changed files with 85 additions and 125 deletions

View file

@ -37,21 +37,21 @@ release.
release_date = "October 01, 2021"
```
3. Commit the changes.
4. Tag the branch with the spec release with a format of `v1.2` (if releasing Matrix 1.2).
5. Push the release branch and the tag.
6. 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.
7. Check out and fast-forward `main` to the release branch.
8. Generate the changelog. This is done *after* the tagging to ensure the rendered
changelog makes sense.
4. Generate the changelog.
1. Activate your python virtual environment.
2. Run `./scripts/generate-changelog.sh v1.2 "October 01, 2021"` (using the correct
version number and same `release_date` format from the hugo config).
3. Commit the result.
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.
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.
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.
9. Create a new release on GitHub from the newly created tag.
* The title should be just "v1.2" (for example).
* The description should be a copy/paste of the changelog. The generated changelog
will be at `content/partials/changelogs/v1.2.md` - copy/paste verbatim.
will be at `content/changelog/v1.2.md` - copy/paste verbatim.
* Upload the artifacts of the GitHub Actions build for the release to the GitHub
release as artifacts themselves. This should be the tarball that will be deployed
to spec.matrix.org.