RELEASE.md: add instructions for React dep updates (#6831)

* RELEASE.md: add instructions for React dep updates

Signed-off-by: Julius Volz <julius.volz@gmail.com>
This commit is contained in:
Julius Volz 2020-09-16 13:36:53 +02:00 committed by GitHub
parent 6f28c46f4c
commit fc416e309b
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23

View file

@ -62,13 +62,7 @@ Maintaining the release branches for older minor releases happens on a best effo
### 0. Updating dependencies ### 0. Updating dependencies
A few days before a major or minor release, consider updating the dependencies: A few days before a major or minor release, consider updating the dependencies.
```
make update-go-deps
git add go.mod go.sum vendor
git commit -m "Update dependencies"
```
Then create a pull request against the master branch. Then create a pull request against the master branch.
@ -81,6 +75,32 @@ you can skip the dependency update or only update select dependencies. In such a
case, you have to create an issue or pull request in the GitHub project for case, you have to create an issue or pull request in the GitHub project for
later follow-up. later follow-up.
#### Updating Go dependencies
```
make update-go-deps
git add go.mod go.sum vendor
git commit -m "Update dependencies"
```
#### Updating React dependencies
Either upgrade the dependencies within their existing version constraints as specified in the `package.json` file (see https://docs.npmjs.com/files/package.json#dependencies):
```
cd web/ui/react-app
yarn upgrade
git add yarn.lock
```
Or alternatively, update all dependencies to their latest major versions. This is potentially more disruptive and will require more follow-up fixes, but should be done from time to time (use your best judgement):
```
cd web/ui/react-app
yarn upgrade --latest
git add package.json yarn.lock
```
### 1. Prepare your release ### 1. Prepare your release
At the start of a new major or minor release cycle create the corresponding release branch based on the master branch. For example if we're releasing `2.17.0` and the previous stable release is `2.16.0` we need to create a `release-2.17` branch. Note that all releases are handled in protected release branches, see the above `Branch management and versioning` section. Release candidates and patch releases for any given major or minor release happen in the same `release-<major>.<minor>` branch. Do not create `release-<version>` for patch or release candidate releases. At the start of a new major or minor release cycle create the corresponding release branch based on the master branch. For example if we're releasing `2.17.0` and the previous stable release is `2.16.0` we need to create a `release-2.17` branch. Note that all releases are handled in protected release branches, see the above `Branch management and versioning` section. Release candidates and patch releases for any given major or minor release happen in the same `release-<major>.<minor>` branch. Do not create `release-<version>` for patch or release candidate releases.