-
Notifications
You must be signed in to change notification settings - Fork 10
Releasing
Use the following process to release a new version of exodus-rsync.
- Update CHANGELOG.md with a section for the new version (example).
- Git tag & GitHub release will automatically be created based on the new version.
The rest of this page explains the steps in more detail.
You must determine what the version number should be for the next release.
We use Semantic Versioning. In summary, where the current version is X.Y.Z, then:
- If release will contain backwards-incompatible changes: new version is (X+1).0.0 (MAJOR bump)
- Otherwise, if release contains new features, new version is X.(Y+1).0 (MINOR bump)
- Otherwise, new version is X.Y.(Z+1) (PATCH bump)
If you are not sure whether the changes in the release count as "new features" or not, don't worry about it too much, just do a MINOR bump.
Prepare an update to CHANGELOG.md.
You should change the current "Unreleased" section to have the new version number and date, and also add a new empty "Unreleased" section on top.
For example, if the new version is 1.2.3 and today is 2025-01-02 (YYYY-MM-DD) then the top of the changelog should look something like:
# Changelog
## Unreleased
- n/a
## 1.2.3 - 2025-01-02
- Something which changed in this release.
- Something else which also changed.
## 1.2.2 - 2024-12-23
- Something which changed in this older release
(...and so on)
Ideally, the "Unreleased" section of the changelog already contained useful messages leading up to the release and you simply need to change the section header. However, this can easily be forgotten. If there are obvious gaps or mistakes in the changelog you should attempt to fix them at this time.
Push the CHANGELOG.md update using the usual pull request workflow, e.g. make a PR from your fork, allow it to be reviewed, and submit it once approved.
Check the releases page to verify that the new release shows up as expected, with an exodus-rsync binary attached.
If it doesn't appear within ~5 minutes or so, check the GitHub Actions attached to the repo for any errors.
If required, it is possible to manually trigger the tag/release workflow (e.g. to retry the release after problems have been resolved). It is safe to run the workflow several times; it won't overwrite existing tags or release assets.