-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
15bac99
commit 077bbfa
Showing
1 changed file
with
38 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,38 @@ | ||
# Guidelines for New Releases | ||
|
||
Let's assume we have a stable `dev` branch with all the features, bug fixes | ||
and any other changes that we may want to add for an upcoming new release. | ||
|
||
We may now follow these steps: | ||
|
||
1. Pick a version number. If current version is `vX.Y.Z`, next version will be: | ||
|
||
- `X.Y.Z+1`: if it includes bug fixes, chores or other minor changes. (AKA patch release). | ||
- `X.Y+1.Z`: if it includes new features. (AKA minor release). | ||
- `X+1.Y.Z`: if it's a complete new version, with either major functionality | ||
changes, a new API or a complete new UI design (AKA major release). | ||
|
||
1. Bump the version number in [`package.json`](./package.json), commit and open | ||
a PR to `dev`. Make sure the PR is squashed as a single commit with the | ||
format `[chore] version bump - vX.Y.Z"` (something like `vX.Y.Z` is fine too). | ||
|
||
1. Open a new PR to merge `dev` into `main`. Wait for the basic tests to run. | ||
Ask another dev to review this PR. | ||
|
||
1. If the tests are okay and the PR is approved, **make sure it is merged using a merge commit**, | ||
DO NOT SQUASH. | ||
|
||
1. Immediately after merging into `main`, go to [release](https://github.com/AlphadayHQ/frontend/releases) | ||
and click on "draft a new release". Make sure the release targets `main` and create a new tag called `vX.Y.Z`. | ||
Include autogenerated logs. Mark is a pre-release if that is the case. | ||
|
||
1. At this point, a Github action will already rollout an **staging** release. | ||
|
||
1. **Deploy to Production**: If the staging release is stable and QA-approved, | ||
we should now be able to rollout a new production release. Production deployments | ||
are manually triggered from the [actions](https://github.com/AlphadayHQ/frontend/actions) | ||
menu in Github's UI (see _Deploy to Production_). **Make sure you choose the `main` branch**. | ||
|
||
1. If the staging version has bugs, we'll add bug fixes in the `dev` branch, and version `vX.Y.Z` will be skipped in production. We'll instead move back to step `2.` and try a new hot-fix release `vX.Y.Z+1` including the bug fixes found in staging. | ||
|
||
1. If the production version has bugs and a hotfix is needed, we add the bug fixes to a hot-fix branch that stems from the `main` branch. The version of this branch is bumped to `vX.Y.Z-hotfix` and then released to production. Once the hotfix is released, The bug fixes should also be added to the `main` branch |