Release checklist
This is a list of steps needed to perform a new graphANNIS release.
GraphANNIS uses semantic versioning. Language bindings can have their own version number, but should state which core version is used in its documentation.
- Create and push a new release branch
release/<version>from thedevelopbranch for feature releases. If you make a bug-fix release, create a branch namedhotfix/<version>from themasterbranch. - If this is a major or minor release, update the link to the Developer Guide documentation in the
README.mdto point to the new version short version, omitting the patch level and with adding a āvā prefix (e.g. https://korpling.github.io/graphANNIS/docs/v1.0/) - Release the branch with the cargo-release plugin
cargo release releaseto release the current development version (e.g. 1.0.0-dev will be released as 1.0.0)cargo release patchfor hotfixes updates (e.g. 1.0.0 to 1.0.1)cargo release minorfor minor updates (e.g. 1.0.1 to 1.1.0)cargo release majorfor major updates (e.g. 1.1.0 to 2.0.0)
- Merge the release branch both into the master and develop branch then delete the release branch.
- Create the release on GitHub, copy the changelog entry as release notes. Save the release as draft
- Wait for Continuous Integration (CI) to finish building the release artifacts for all systems and then publish the drafted release
- Update and release language bindings
In addition, for the binaries, CI will also build and publish the documentation using the gh-pages branch and a sub-folder docs/<short-version>, e.g. https://korpling.github.io/graphANNIS/docs/v0.22/.