Release 3.1.0

[marcelosalloum]

Release Checklist

Attention: the examples below use the version x.y.z but you should update
them to use the version you're releasing.

Git Preparation

• Decide on a version number based on the current version number and the
  common rules defined in Semantic Versioning. E.g.
  x.y.z.
• Update this ticket name to reflect the new version number, following the
  pattern "Release x.y.z".
• Cut a branch for the new release out of the develop branch, following
  the gitflow naming pattern release/x.y.z.

Code Preparation

• Update the project's version in package.json accordingly.
• Update the CHANGELOG.md with the new version number and release notes.
• Run tests and linting, and make sure the version running in the default
  branch is working end-to-end. At least the minimal end-to-end manual tests
  is mandatory.
• 🚨 DO NOT RELEASE before holidays or weekends! Mondays and Tuesdays are
  preferred. This doesn't apply if you're releasing a release-candidate
  (pre-release).

Merging the Branches

🚨 ATTENTION: in the following steps, do merge commits and NOT
squash-and-merge!

• When the team is confident the release is stable, you'll need to create
  two pull requests:
  • release/x.y.z -> main: This PR should be merged with a merge commit.
    Skip this step if releasing a release-candidate (pre-release). Release 3.1.0 to main #209
  • release/x.y.z -> develop: this should be merged after the main
    branch is merged. This PR should be merged with a merge commit.

Publishing the Release

• After the release branch is merged to main, create a new release on
  GitHub with the name x.y.z and the use the same changes from the
  CHANGELOG.md file.
  • The release should automatically publish a new version of the docker
    image to Docker Hub. Double check if that happened.