easylinux/kube-prometheus
1
0
Fork 0
Code Issues Pull Requests Actions Packages 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
1 changed files with 9 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
RELEASE.md
View File

@@ -1,13 +1,12 @@
# Release schedule
Kube-prometheus has a somehow predictable release schedule, releases were
historically cut in sync with OpenShift releases as per downstream needs.
kube-prometheus will follow the Kubernetes release schedule.
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
to changing needs and requirements in the OpenShift release process.
We do not guarantee backports from the `main` branch to older release branches.
For every new Kubernetes release, there will be a corresponding new release
of kube-prometheus, although it tends to happen later.
This differs from the previous release schedule, which was driven by OpenShift releases.
# 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
`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
to merge bug fixes into the latest release branch. Bug fixes are then merged
into master from the latest release branch. The master branch should always
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.
The usual flow is to merge new features, changes and bug fixes into the `main` branch.
The decision to backport bugfixes into release branches is made on a case-by-case basis.
Maintaining the release branches for older minor releases is best-effort.
## Update components version
@@ -47,7 +38,7 @@ failed or because the main branch was already up-to-date.
## 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
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