mirrors/kube-prometheus
1
0
Fork 0
mirror of https://github.com/prometheus-operator/kube-prometheus.git synced 2025-10-05 12:21:23 +02:00
Code Issues Projects Releases Wiki Activity

docs: Update release doc/schedule info (#2508)

Browse Source
This commit is contained in:
Philip Gough 2024-09-10 10:27:17 +01:00 committed by GitHub
parent 1d5dec22b9
commit 74cadfed37
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 9 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
RELEASE.md
View File

@ -1,13 +1,12 @@
# Release schedule # Release schedule
Kube-prometheus has a somehow predictable release schedule, releases were kube-prometheus will follow the Kubernetes release schedule.
historically cut in sync with OpenShift releases as per downstream needs. For every new Kubernetes release, there will be a corresponding minor release of
kube-prometheus, although it may not be immediate.
This has been changed in favour of tracking upstream Kubernetes releases due We do not guarantee backports from the `main` branch to older release branches.
to changing needs and requirements in the OpenShift release process.
For every new Kubernetes release, there will be a corresponding new release This differs from the previous release schedule, which was driven by OpenShift releases.
of kube-prometheus, although it tends to happen later.
# How to cut a new release # How to cut a new release
@ -21,17 +20,9 @@ We use [Semantic Versioning](http://semver.org/).
We maintain a separate branch for each minor release, named We maintain a separate branch for each minor release, named
`release-<major>.<minor>`, e.g. `release-1.1`, `release-2.0`. `release-<major>.<minor>`, e.g. `release-1.1`, `release-2.0`.
The usual flow is to merge new features and changes into the master branch and The usual flow is to merge new features, changes and bug fixes into the `main` branch.
to merge bug fixes into the latest release branch. Bug fixes are then merged The decision to backport bugfixes into release branches is made on a case-by-case basis.
into master from the latest release branch. The master branch should always Maintaining the release branches for older minor releases is best-effort.
contain all commits from the latest release branch.
If a bug fix got accidentally merged into master, cherry-pick commits have to be
created in the latest release branch, which then has to be merged back into
master. Try to avoid that situation.
Maintaining the release branches for older minor releases happens on a best
effort basis.
## Update components version ## Update components version
@ -47,7 +38,7 @@ failed or because the main branch was already up-to-date.
## Update Kubernetes supported versions ## Update Kubernetes supported versions
The main branch of kube-prometheus should support the last 2 versions of The `main` branch of kube-prometheus should support the last 2 versions of
Kubernetes. We need to make sure that the CI on the main branch is testing the Kubernetes. We need to make sure that the CI on the main branch is testing the
kube-prometheus configuration against both of these versions by updating the [CI kube-prometheus configuration against both of these versions by updating the [CI
worklow](.github/workflows/ci.yaml) to include the latest kind version and the worklow](.github/workflows/ci.yaml) to include the latest kind version and the