mudhorn/prometheus
1
0
Fork 0
mirror of https://github.com/prometheus/prometheus.git synced 2024-11-09 23:24:05 -08:00
Code Issues Actions 3 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

36
RELEASE.md
View file

@ -38,7 +38,7 @@ The release shepherd is responsible for the entire release series of a minor rel
* We aim to keep the master branch in a working state at all times. In principle, it should be possible to cut a release from master at any time. In practice, things might not work out as nicely. A few days before the pre-release is scheduled, the shepherd should check the state of master. Following their best judgement, the shepherd should try to expedite bug fixes that are still in progress but should make it into the release. On the other hand, the shepherd may hold back merging last-minute invasive and risky changes that are better suited for the next minor release.
* On the date listed in the table above, the release shepherd cuts the first pre-release (using the suffix `-rc.0`) and creates a new branch called `release-<major>.<minor>` starting at the commit tagged for the pre-release. In general, a pre-release is considered a release candidate (that's what `rc` stands for) and should therefore not contain any known bugs that are planned to be fixed in the final release.
* With the pre-release, the release shepherd is responsible for running and monitoring a benchmark run of the pre-release for 3 days, after which, if successful, the pre-release is promoted to a stable release.
* If regressions or critical bugs are detected, they need to get fixed before cutting a new pre-release (called `-rc.1`, `-rc.2`, etc.).
* If regressions or critical bugs are detected, they need to get fixed before cutting a new pre-release (called `-rc.1`, `-rc.2`, etc.).
See the next section for details on cutting an individual release.
@ -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.