-
Notifications
You must be signed in to change notification settings - Fork 5
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
docs: update contributing guide and release documentation (#90)
* update CONTRIBUTING.md * Apply suggestions from code review Co-authored-by: Tom Longridge <tom@bugsnag.com> * docs: 📝 update documentation * revert: 🔥 remove unnuecessary comment * docs: 📝 update RELEASES.md * docs: 📝 update RELEASES.md * docs: 📝 rename RELEASING.md * docs: 📝 update CONTRIBUTING.md * Update docs/RELEASING.md Co-authored-by: Yousif <74918474+yousif-bugsnag@users.noreply.github.com> --------- Co-authored-by: Tom Longridge <tom@bugsnag.com> Co-authored-by: Yousif Ahmed <yousif@bugsnag.com> Co-authored-by: Yousif <74918474+yousif-bugsnag@users.noreply.github.com>
- Loading branch information
4 people
authored
Sep 2, 2024
1 parent
db94d34
commit 792a2d1
Showing
3 changed files
with
154 additions
and
110 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
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,123 @@ | ||
| # Releasing | ||
|
|
||
| ## Create a release branch | ||
|
|
||
| ### Enhancements and bug fixes | ||
|
|
||
| - decide on a new version number, following [semantic versioning](https://semver.org/) | ||
| - create a new release branch from `vX/next` with the new version number in the branch name i.e. `git checkout -b release/vX.Y.Z` | ||
| - update the version number and date in the changelog | ||
| - make a pull request from your release branch to `vX/main` entitled "Release vX.Y.Z" | ||
| - get the pull request reviewed – all code changes should have been reviewed already, this should be a review of the integration of all changes to be shipped and the changelog | ||
| - merge the PR | ||
|
|
||
| ⚠️ **Note**: Consider merging or cherry-picking the fix to other affected major version branches | ||
|
|
||
| ### New major release | ||
|
|
||
| When a new Expo SDK is released, we should also publish a matching major version. | ||
|
|
||
| - create and push a new **main** branch for the new supported Expo version (e.g. `v48/main`) from the latest current branch (e.g. `v47/main`), checking for unreleased changes in the equivalent `next` branch (e.g. `v47/next`) | ||
| - create a new **next** branch based on the new **main** branch (e.g. `v48/next`) | ||
| - create a feature branch from which the changes to support the new version are to be made (e.g. `PLAT-1234-support-v48`) | ||
| - make the required dependency and CLI changes for the latest Expo version (see [Keeping dependencies in sync](#keeping-dependencies-in-sync)) | ||
| - regenerate the e2e test fixture using the `create-expo-app` cli | ||
| - make a PR from the feature branch targeting the new **next** branch (e.g. `PLAT-1234-support-v48` to `v48/next`) | ||
| - create a release branch from **next** (e.g. `release/v48.0.0`) | ||
| - update the version number and release date in the changelog | ||
| - make a PR from your release branch targeting the new **main** branch (e.g. `release/v48.0.0` to `v48/main`) entitled `Release v48.0.0` | ||
| - get the release PR reviewed | ||
| - merge the PR | ||
|
|
||
| The following digram demonstrates the flow of creating the required branches for new SDK release: | ||
|
|
||
| ```mermaid | ||
| graph TD; | ||
| v47/main-->v48/main; | ||
| v48/main-->v48/next; | ||
| v48/next-->PLAT-1234-support-v48; | ||
| PLAT-1234-support-v48-. PR .->v48/next; | ||
| v48/next-->release/v48; | ||
| release/v48-. PR .->v48/main; | ||
| ``` | ||
|
|
||
| ## Publish the release | ||
|
|
||
| You are now ready to make the release. Releases are done using Docker. You do not need to have the release branch checked out on your local machine to make a release – the container pulls a fresh clone of the repo down from GitHub. | ||
|
|
||
| ### Prerequisites | ||
|
|
||
| - You will need to clone the repository and have Docker running on your local machine. | ||
| - Ensure you are logged in to npm and that you have access to publish to the following on npm | ||
| - any packages in the `@bugsnag` namespace | ||
| - the `bugsnag-expo-cli` package | ||
| - Ensure your `.gitconfig` file in your home directory is configured to contain your name and email address | ||
| - Generate a [personal access token](https://github.com/settings/tokens/new) on GitHub and store it somewhere secure | ||
|
|
||
| ### Building | ||
|
|
||
| Before publishing your release, you must first build the release container: | ||
|
|
||
| `docker-compose build release` | ||
|
|
||
| ### Publishing | ||
|
|
||
| You may want to consider shipping a [prerelease](#prerelease) to aid testing the changes before publishing | ||
|
|
||
| ```sh | ||
| GITHUB_USER=<your github username> \ | ||
| GITHUB_ACCESS_TOKEN=<generate a personal access token> \ | ||
| RELEASE_BRANCH=<the branch to publish a new release from> \ | ||
| VERSION=[major | minor | patch] \ | ||
| docker-compose run release | ||
| ``` | ||
|
|
||
| This process is interactive and will require you to confirm that you want to publish the changed packages. It will also prompt for 2FA. | ||
|
|
||
| **Note**: if a prerelease was made, to graduate it into a normal release you will need to use `patch` as the version. | ||
|
|
||
| ### Final Steps | ||
|
|
||
| After publishing the release, the following steps must also be completed: | ||
|
|
||
| - create a release on GitHub https://github.com/bugsnag/bugsnag-expo/releases/new | ||
| - use the tag vX.Y.Z as the name of the release | ||
| - copy the release notes from `CHANGELOG.md` | ||
| - publish the release | ||
| - update and push `vX/next`: | ||
| ```sh | ||
| git checkout v48/next | ||
| git merge v48/main | ||
| git push | ||
| ``` | ||
| - for new major versions: | ||
| - change the default branch on GitHub to the new `vX/next` branch | ||
| - update the `@bugsnag/js` pipeline on Buildkite so that it always triggers the latest 3 expo versions | ||
|
|
||
| ### Prereleases | ||
|
|
||
| If you are starting a new prerelease, use one of the following values for the `VERSION` variable in the release command: | ||
|
|
||
| ``` | ||
| VERSION=[premajor | preminor | prepatch] | ||
| ``` | ||
|
|
||
| For subsequent iterations on that release, use: | ||
|
|
||
| ``` | ||
| VERSION=prerelease | ||
| ``` | ||
|
|
||
| For example: | ||
|
|
||
| ``` | ||
| GITHUB_USER=<your github username> \ | ||
| GITHUB_ACCESS_TOKEN=<generate a personal access token> \ | ||
| RELEASE_BRANCH=<the branch to publish a new release from> \ | ||
| VERSION=preminor \ | ||
| docker-compose run release | ||
| ``` | ||
|
|
||
| Prereleases will automatically be published to npm with the dist tag `next`. | ||
|
|
||
| The dist tag ensures that prereleases are not installed by unsuspecting users who do not specify a version – npm automatically adds the `latest` tag to a published module unless one is specified. |
File renamed without changes.