-
-
Notifications
You must be signed in to change notification settings - Fork 10.3k
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
3821d86
commit 230181d
Showing
1 changed file
with
45 additions
and
32 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 |
|---|---|---|
|
|
@@ -4,25 +4,30 @@ | |
|
|
||
| New releases should be created from release branches originating from the `dev` branch. When you are ready to begin the release process: | ||
|
|
||
| - Make sure you've pulled all the changes from GitHub for both `dev` and `main` branches. | ||
| - Check out the `dev` branch. | ||
| - Create a new `release-next` branch (eg, `git checkout -b release-next`). | ||
| - Technically, any `release-*next*` branch name will work as this is what triggers our GitHub CI workflow that will ultimately publish the release - but we just always use `release-next` | ||
| - Merge `main` into the release branch. | ||
| - Make sure you've pulled all the changes from GitHub for both `dev` and `main` branches | ||
| - Check out the `dev` branch | ||
| - Create a new `release-next` branch (eg, `git checkout -b release-next`) | ||
| - Technically, any `release-*` branch name will work as this is what triggers our GitHub CI workflow that will ultimately publish the release - but we just always use `release-next` | ||
| - We are using `release-v6` for [ongoing v6 releases](#6x-releases-from-the-v6-branch) | ||
| - Merge `main` into the release branch | ||
|
|
||
| Changesets will do most of the heavy lifting for our releases. When changes are made to the codebase, an accompanying changeset file should be included to document the change. Those files will dictate how Changesets will version our packages and what shows up in the changelogs. | ||
|
|
||
| ### Starting a new pre-release | ||
|
|
||
| - Ensure you are on the new `release-next` branch. | ||
| - Enter Changesets pre-release mode using the `pre` tag: `pnpm changeset pre enter pre`. | ||
| - Commit the change and push the `release-next` branch to GitHub. | ||
| - Wait for the release workflow to finish. The Changesets action in the workflow will open a PR that will increment all versions and generate the changelogs. | ||
| - Ensure you are on the new `release-next` branch | ||
| - Enter Changesets pre-release mode using the `pre` tag: | ||
| - `pnpm changeset pre enter pre` | ||
| - Commit the change and push the `release-next` branch to GitHub | ||
| - `git commit -a -m "Enter prerelease mode"` | ||
| - `git push --set-upstream origin release-next` | ||
| - Wait for the release workflow to finish - the Changesets action will open a PR that will increment all versions and generate the changelogs | ||
| - Check out the PR branch created by changesets locally | ||
| - Review the updated `CHANGELOG.md` files in the PR locally and make any adjustments necessary, then merge the PR into the `release-next` branch. | ||
| - _Optional:_ Review the updated `CHANGELOG.md` files in the PR locally and make any adjustments necessary, then merge the PR into the `release-next` branch. | ||
| - `find packages -name 'CHANGELOG.md' -mindepth 2 -maxdepth 2 -exec code {} \;` | ||
| - Usually for prereleases there's not much to change here because the prerelease sections will be deleted prior to the final stable release anyway | ||
| - Once the changesets files are in good shape, merge the PR to `release-next` | ||
| - Once the PR is merged, the release workflow will publish the updated `X.Y.Z-pre.*` packages to npm. | ||
| - Once the PR is merged, the release workflow will publish the updated `X.Y.Z-pre.*` packages to npm | ||
| - At this point, you can begin crafting the release notes for the eventual stable release in the root `CHANGELOG.md` file in the repo | ||
| - Copy the template for a new release and update the version numbers and links accordingly | ||
| - Copy the relevant changelog entries from all packages into the release notes and adjust accordingly | ||
|
|
@@ -33,28 +38,30 @@ Changesets will do most of the heavy lifting for our releases. When changes are | |
| You may need to make changes to a pre-release prior to publishing a final stable release. To do so: | ||
|
|
||
| - Branch off of `release-next` and make whatever changes you need | ||
| - Create a new changeset: `pnpm changeset`. | ||
| - **IMPORTANT:** This is required even if you ultimately don't want to include these changes in the logs. Remember, changelogs can be edited prior to publishing, but the Changeset version script needs to see new changesets in order to create a new version. | ||
| - Push your branch to GitHub and PR it to `release-next`. | ||
| - Once reviewed/approved, merge the PR to the `release-next` branch. | ||
| - Wait for the release workflow to finish and the Changesets action to open its PR that will increment all versions. | ||
| - Review the PR, make any adjustments necessary, and merge it into the `release-next` branch. | ||
| - Once the PR is merged, the release workflow will publish the updated `X.Y.Z-pre.*` packages to npm. | ||
| - Create a new changeset: `pnpm changeset` | ||
| - **IMPORTANT:** This is required even if you ultimately don't want to include these changes in the logs. Remember, changelogs can be edited prior to publishing, but the Changeset version script needs to see new changesets in order to create a new version | ||
| - Push your branch to GitHub and PR it to `release-next` | ||
| - Once reviewed/approved, merge the PR to the `release-next` branch | ||
| - Wait for the release workflow to finish and the Changesets action to open its PR that will increment all versions | ||
| - Note: If more changes are needed you can just merge them to `release-next` and this PR will automatically update in place | ||
| - Review the PR, make any adjustments necessary, and merge it into the `release-next` branch | ||
| - Once the PR is merged, the release workflow will publish the updated `X.Y.Z-pre.*` packages to npm | ||
| - Make sure you copy over the new changeset contents into stable release notes in the root `CHANGELOG.md` file in the repo | ||
|
|
||
| ### Publishing the stable release | ||
|
|
||
| - Exit Changesets pre-release mode in the `release-next` branch: `pnpm changeset pre exit`. | ||
| - Commit the edited pre-release file along with any unpublished changesets, and push the `release-next` branch to GitHub. | ||
| - Wait for the release workflow to finish. The Changesets action in the workflow will open a PR that will increment all versions and generate the changelogs for the stable release. | ||
| - Review the updated `CHANGELOG` files in the PR and make any adjustments necessary. | ||
| - Exit Changesets pre-release mode in the `release-next` branch: | ||
| - `pnpm changeset pre exit` | ||
| - Commit the edited pre-release file along with any unpublished changesets, and push the `release-next` branch to GitHub | ||
| - Wait for the release workflow to finish - the Changesets action in the workflow will open a PR that will increment all versions and generate the changelogs for the stable release | ||
| - Review the updated `CHANGELOG` files in the PR and make any adjustments necessary | ||
| - `find packages -name 'CHANGELOG.md' -mindepth 2 -maxdepth 2 -exec code {} \;` | ||
| - Our automated release process should have removed prerelease entries | ||
| - Finalize the release notes | ||
| - This should already be in pretty good shape in the root `CHANGELOG.md` file in the repo | ||
| - This should already be in pretty good shape in the root `CHANGELOG.md` file in the repo because changes have been added with each prerelease | ||
| - Do a quick double check that all iterated prerelease changesets got copied over | ||
| - Merge the PR into the `release-next` branch. | ||
| - Once the PR is merged, the release workflow will publish the updated packages to npm. | ||
| - Merge the PR into the `release-next` branch | ||
| - Once the PR is merged, the release workflow will publish the updated packages to npm | ||
| - Once the release is published: | ||
| - Pull the latest `release-next` branch containing the PR you just merged | ||
| - Merge the `release-next` branch into `main` **using a non-fast-forward merge** and push it up to GitHub | ||
|
|
@@ -79,23 +86,29 @@ After the `6.25.0` release, we branched off a `v6` branch for continued `6.x` wo | |
| - Changes for 6.x should be PR'd to the `v6` branch with a changeset | ||
| - Once merged, cherry-pick or re-do those changes against the `dev` branch so that they show up in v7 | ||
| - This does not apply to things like adding deprecation warnings that should not land in v7 | ||
| - You should not include a changelog in your commit to `dev` | ||
| - You should not include a changeset in your commit to `dev` | ||
| - Starting the release process for 6.x is the same as outlined above, with a few changes: | ||
| - Branch from `v6` instead of `dev` | ||
| - Do not merge `main` into the `release-*` branch | ||
| - Use the name `release-v6` to avoid collisions with the ongoing v7 (pre)releases using `release-next` | ||
| - Do not merge `main` into the `release-v6` branch | ||
| - The process of the PRs and iterating on prereleases remains the same | ||
| - Once the stable release is out: | ||
| - Merge `release-next` back to `v6` with a **Normal Merge** | ||
| - Patch the changes into `main` | ||
| - `git checkout main` | ||
| - `git diff [email protected]@6.26.2 > ./changes.patch` | ||
| - `git apply changes.patch` | ||
| - Merge `release-v6` back to `v6` with a **Normal Merge** | ||
| - Copy the updated changelog entry for the `6.X.Y` version to `main` | ||
| - The _code_ changes should already be in the `dev` branch but confirm that the commits in this release are all included in `dev` already: | ||
| - I.e., https://github.com/remix-run/react-router/compare/[email protected]@6.26.2 | ||
| - If one or more are not, then you can manually bring them over by cherry-picking the commit (or re-doing the work) | ||
| - You should not include a changelog in your commit to `dev` | ||
| - Copy the updated changelogs from `release-next` over to `dev` so the changelogs continue to reflect this new 6x release into the v7 releases | ||
|
|
||
| ### Notes on 7.0.0-pre.N released during the v7 prerelease | ||
|
|
||
| During the v7 prerelease, the process for iterating and shipping a new `7.0.0-pre.N` release is slightly more streamlined than the steps outlined [above](#iterating-a-pre-release). Because we want _everything_ in `dev` to ship in the prerelease, cutting a new prerelease is simply: | ||
|
|
||
| - Merge `dev` -> `release-next` | ||
| - This will include the changesets for changes committed to `dev` since the last prerelease | ||
| - This will automatically open a new Changesets PR for the new prerelease version | ||
|
|
||
| ### Experimental releases | ||
|
|
||
| Experimental releases and hot-fixes do not need to be branched off of `dev`. Experimental releases can be branched from anywhere as they are not intended for general use. | ||
|
|
||