@ -62,13 +62,7 @@ Maintaining the release branches for older minor releases happens on a best effo
### 0. Updating 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"
```
A few days before a major or minor release, consider updating the dependencies.
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
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
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.
Julius Volz
4 years ago
committed by