mudhorn/prometheus
1
0
Fork 0
mirror of https://github.com/prometheus/prometheus.git synced 2025-02-21 03:16:00 -08:00
Code Issues Actions 4 Packages Projects Releases Wiki Activity

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

Browse source 
* 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
1 changed files with 28 additions and 8 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

34
RELEASE.md
View file

@ -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.