From 2517e1ac21f8c0763eb355ffd77511946ebae589 Mon Sep 17 00:00:00 2001 From: Demian Katz Date: Thu, 12 Dec 2024 07:52:53 -0500 Subject: [PATCH] Fix logical flaw. --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 6a9e8b4f3..2d4447bfe 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -112,7 +112,7 @@ Once a stable release is ready to be published, these steps can be followed by t 1. On the `release-X.Y.Z` branch, run `npm version X.Y.Z` (replacing "X.Y.Z" with the actual number of the new version) to appropriately update `package.json` and create a Git tag. 2. Merge the `release-X.Y.Z` branch into both `dev` and the matching `release-X.Y` branch. Create the `release-X.Y` branch if it does not already exist. The `release-X.Y` branch will be long-lived, used to create backported patch releases as needed; the `release-X.Y.Z` branch will be deleted as part of the release process, as it is no longer needed. -3. Merge the `dev` branch into the `main` branch, so that `main` continues to point to the most recent stable release. +3. Merge the `release-X.Y` branch into the `main` branch, so that `main` continues to point to the most recent stable release. 4. All changed branches and newly-created/deleted release tags must be pushed to GitHub; e.g. `git push origin main dev v4.1.0 release-4.1 :release-4.1.0`. (Note the colon on `:release-4.1.0` -- this deletes the short-lived release branch while updating all of the long-lived branches). 5. At this point, a GitHub action will recognize the new version tag and publish the package to NPM.