From e158907cb4eb7f55bfe50f36f52325771509c994 Mon Sep 17 00:00:00 2001
From: Stacey Van Herk <13419300+svanherk@users.noreply.github.com>
Date: Thu, 11 Jan 2024 10:01:15 -0500
Subject: [PATCH] feat: GAUD-292 - Use new release token (#60)

* GAUD-292 - Use new release token
* Switch to node 20
* Update README
---
 .github/workflows/release.yml |  2 +-
 .nvmrc                        |  2 +-
 README.md                     | 39 +++--------------------------------
 3 files changed, 5 insertions(+), 38 deletions(-)

diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml
index 38eba58..1136ba0 100644
--- a/.github/workflows/release.yml
+++ b/.github/workflows/release.yml
@@ -21,6 +21,6 @@ jobs:
       - name: Semantic Release
         uses: BrightspaceUI/actions/semantic-release@main
         with:
-          GITHUB_TOKEN: ${{ secrets.D2L_GITHUB_TOKEN }}
+          GITHUB_TOKEN: ${{ secrets.D2L_RELEASE_TOKEN }}
           NPM: true
           NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
diff --git a/.nvmrc b/.nvmrc
index 3c03207..209e3ef 100644
--- a/.nvmrc
+++ b/.nvmrc
@@ -1 +1 @@
-18
+20
diff --git a/README.md b/README.md
index 43910b9..15f051d 100644
--- a/README.md
+++ b/README.md
@@ -71,41 +71,8 @@ By default `d2l-fetch-simple-cache` will cache responses for 2 minutes, or the t
 * `cache-control: no-store` will indicate that the Response returned from the server should not be cached. **Note that this does not prevent the Request from being served from an existing valid cached Response**.
 * `cache-control: max-age=<seconds>` can be used to override the configured middleware time-to-live. For example if the middleware is configured with the default 2 minute TTL a Request sent with a header of `cache-control: max-age=60` will only be cached for 60 seconds. **Note that if a previous matching Request had already been cached the shorter of the two values (middleware configuration and `max-age` header value) will be used for determining cache expiry**.
 
-## Versioning & Releasing
+## Versioning and Releasing
 
-> TL;DR: Commits prefixed with `fix:` and `feat:` will trigger patch and minor releases when merged to `main`. Read on for more details...
+This repo is configured to use `semantic-release`. Commits prefixed with `fix:` and `feat:` will trigger patch and minor releases when merged to `main`.
 
-The [semantic-release GitHub Action](https://github.com/BrightspaceUI/actions/tree/main/semantic-release) is called from the `release.yml` GitHub Action workflow to handle version changes and releasing.
-
-### Version Changes
-
-All version changes should obey [semantic versioning](https://semver.org/) rules:
-1. **MAJOR** version when you make incompatible API changes,
-2. **MINOR** version when you add functionality in a backwards compatible manner, and
-3. **PATCH** version when you make backwards compatible bug fixes.
-
-The next version number will be determined from the commit messages since the previous release. Our semantic-release configuration uses the [Angular convention](https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog-angular) when analyzing commits:
-* Commits which are prefixed with `fix:` or `perf:` will trigger a `patch` release. Example: `fix: validate input before using`
-* Commits which are prefixed with `feat:` will trigger a `minor` release. Example: `feat: add toggle() method`
-* To trigger a MAJOR release, include `BREAKING CHANGE:` with a space or two newlines in the footer of the commit message
-* Other suggested prefixes which will **NOT** trigger a release: `build:`, `ci:`, `docs:`, `style:`, `refactor:` and `test:`. Example: `docs: adding README for new component`
-
-To revert a change, add the `revert:` prefix to the original commit message. This will cause the reverted change to be omitted from the release notes. Example: `revert: fix: validate input before using`.
-
-### Releases
-
-When a release is triggered, it will:
-* Update the version in `package.json`
-* Tag the commit
-* Create a GitHub release (including release notes)
-* Deploy a new package to NPM
-
-### Releasing from Maintenance Branches
-
-Occasionally you'll want to backport a feature or bug fix to an older release. `semantic-release` refers to these as [maintenance branches](https://semantic-release.gitbook.io/semantic-release/usage/workflow-configuration#maintenance-branches).
-
-Maintenance branch names should be of the form: `+([0-9])?(.{+([0-9]),x}).x`.
-
-Regular expressions are complicated, but this essentially means branch names should look like:
-* `1.15.x` for patch releases on top of the `1.15` release (after version `1.16` exists)
-* `2.x` for feature releases on top of the `2` release (after version `3` exists)
+To learn how to create major releases and release from maintenance branches, refer to the [semantic-release GitHub Action](https://github.com/BrightspaceUI/actions/tree/main/semantic-release) documentation.
\ No newline at end of file