Releasing¶
Releasing a version of the Anonlink Entity Service¶
We follow gitflow. Each release has a GitHub milestone associated with it which groups all the features and bug fixes together.
Multiple docker images are contained within this repository (e.g., backend
, frontend
, benchmark
) which
are independently versioned. In general a release involves a new version of both the backend
and the frontend
.
This is because the documentation is baked into the frontend so user visible changes to the backend require a new
frontend.
- Choose a new version using semantic versioning.
- Create a branch off the latest
develop
calledrelease-x.y.z
. - Update the versions in the code base (e.g.,
backend/entityservice/VERSION
) of any components that have been changed. As above note if the backend version has changed you must release a new frontend too. - Update the versions in the Chart.yaml file.
- Update the changelog to include user friendly information on all features, taking special care to mention any breaking changes.
- Open a PR to merge these changes into
develop
, and get a code review. Make any requested changes, and merge the changes intodevelop
(don’t close the branch). - Open a PR to merge the release branch into
master
, only proceed if the CI tests all pass. Merge, rather than squashing the commits. - Create a git tag of the form
vX.Y.Z[-aN|-bN]
(e.g. using GitHub’s releases ui). - Tag and push release versions of docker images from this tag and the tag latest (manually for now but ideally using CI).
- Commit to develop (via a PR) creating a new
"Next Version
section in the changelog. - Proudly announce the new release on the anonlink google group https://groups.google.com/forum/#!forum/anonlink