37 lines
1.7 KiB
Markdown
37 lines
1.7 KiB
Markdown
**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/
|
||
|