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 called release-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 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 into develop (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