**Table of Contents**

- [Releasing a New Version](#releasing-a-new-version)
- [Managing the Hotfix Branches](#managing-the-hotfix-branches)

---

## Releasing a New Version

To release a new **Major** or **Minor** version, perform a *no fast-forward* merge from the `master` branch into the `production` branch.

To release a new **Patch** version, perform a *no fast-forward* merge from the `hotfix` branch into the `production` branch.

When GitHub Actions detects updates to the `production` branch, it will automatically trigger the release process.

> [!IMPORTANT]
> Please **do not enable** any check tools such as `Codacy Static Code Analysis` or `commitlint` under the repository’s branch protection rule *Require status checks to pass before merging*. Doing so will prevent GitHub Actions from pushing commits to the `master` branch, which will cause the automated release process to fail.

## Managing the Hotfix Branches

The `hotfix` branch naming format is `hotfix/<MAJOR>.<MINOR>.<PATCH>`, e.g. `hotfix/3.2.1`. It is a temporary branch with a life cycle:

1. Create a new `hotfix` branch from the `production` branch (on GitHub).
2. Commit the patch to the `hotfix` branch by:

   1. Branching from `hotfix` and then committing patches to the new `patch` branch.
   2. Creating a PR for the `patch` branch on GitHub, then squash merge it into the `hotfix` branch.

3. When hotfixes are done, create a PR for the `hotfix` branch and merge it into the `production` branch using the `--no-ff` option.
4. Delete this branch.

[front-matter]: https://jekyllrb.com/docs/front-matter/
[html-compressor]: https://github.com/penibelst/jekyll-compress-html
[ci]: https://en.wikipedia.org/wiki/Continuous_integration
[commitlint]: https://commitlint.js.org/