Skip to content

Document & improve release process

Created by: matthijskooijman

I'm currently working on the 3.0.2 release.

The full release process should be documented somewhere. For now, I'll use this issue to keep notes, this should probably move into the repo somewhere (CONTRIBUTING.md? Or a separate file? In a subdir to keep things clean? Or the wiki?).

I'm basing on https://github.com/projecthamster/hamster/issues/588#issuecomment-600225334 and https://github.com/projecthamster/hamster/projects/1#card-27399663.

Here's the steps I am going through:

  • Update NEWS file. This is done manually, see #607 for some thoughts on automating this. I've only added changes here that affect release users (e.g. visible changes in hamster, but also in the build process, but not the addition of automated tests in github). Where a change has a related PR and issue, I've referenced the issue (since that is typically the issue fixed, and points to the PR anyway. This also seemed existing practice).
  • Bump the version number. In the project card, ederag noted "update version number manually (bumpversion is a time drain)". I wondered a bit about that, since there is a .bumpversion.cfg file in the repo. I tried bumpversion (and also bump2version a more up-to-date fork) which indeed behaved a bit surprising. It might be useful, but for now I just updated the version manually in src/hamster/__init__.py, wscript and .bumpversion.cfg (based on the bumpversion config and earlier bump commits). For the future, maybe we can put the version number just in one place somehow? Maybe even not put the version number in git (so always detect the git version when installing from git), and write the version number (based on the git tag) into the source tarball at release time (automated using a script, maybe even run from a github action).
  • There is probably something that needs to happen with translations. The project card has some related points, but these are outdated according to ederag. Since the 3.0.2 release is not touching any translated strings, I'm just going to leave this for now, but we have to figure this out later.
  • In the project card, a number of steps related to creating the release description are mentioned. In particular, this talks about adding links to the full list of commits, and links to the contributors pages on github (e.g. see https://github.com/projecthamster/hamster/releases/tag/v3.0). I'm not so sure if I want to keep adding those, since people can easily reach the same information using the github interface. Also, I think it would be good if the release description can be prepared beforehand. So we can make a release-PR and once it is merged, just copy the release description out of the PR description or maybe the NEWS file. I tend towards the latter, adding a small release summary above the list of fixed issues in the NEWS file, and maybe also including the list of fixed issues in the release description? Alternatively, we could prepare a draft release in github (along with the release PR), and finalize that to let github create the tag after merging the PR.

I'm out of time for now, but I'll create a PR with the NEWS and version changes soon. Once that is reviewed and merged, a tag and release must be created, which probably be done at the same time through github.