XTesting/kubespray/RELEASE.md

   1 # Release Process
   2
   3 The Kubespray Project is released on an as-needed basis. The process is as follows:
   4
   5 1. An issue is proposing a new release with a changelog since the last release. Please see [a good sample issue](https://github.com/kubernetes-sigs/kubespray/issues/8325)
   6 2. At least one of the [approvers](OWNERS_ALIASES) must approve this release
   7 3. The `kube_version_min_required` variable is set to `n-1`
   8 4. Remove hashes for [EOL versions](https://github.com/kubernetes/website/blob/main/content/en/releases/patch-releases.md) of kubernetes from `*_checksums` variables.
   9 5. Create the release note with [Kubernetes Release Notes Generator](https://github.com/kubernetes/release/blob/master/cmd/release-notes/README.md). See the following `Release note creation` section for the details.
  10 6. An approver creates [new release in GitHub](https://github.com/kubernetes-sigs/kubespray/releases/new) using a version and tag name like `vX.Y.Z` and attaching the release notes
  11 7. An approver creates a release branch in the form `release-X.Y`
  12 8. The corresponding version of [quay.io/kubespray/kubespray:vX.Y.Z](https://quay.io/repository/kubespray/kubespray) and [quay.io/kubespray/vagrant:vX.Y.Z](https://quay.io/repository/kubespray/vagrant) container images are built and tagged. See the following `Container image creation` section for the details.
  13 9. The `KUBESPRAY_VERSION` variable is updated in `.gitlab-ci.yml`
  14 10. The release issue is closed
  15 11. An announcement email is sent to `dev@kubernetes.io` with the subject `[ANNOUNCE] Kubespray $VERSION is released`
  16 12. The topic of the #kubespray channel is updated with `vX.Y.Z is released! | ...`
  17
  18 ## Major/minor releases and milestones
  19
  20 * For major releases (vX.Y) Kubespray maintains one branch (`release-X.Y`). Minor releases (vX.Y.Z) are available only as tags.
  21
  22 * Security patches and bugs might be backported.
  23
  24 * Fixes for major releases (vX.Y) and minor releases (vX.Y.Z) are delivered
  25   via maintenance releases (vX.Y.Z) and assigned to the corresponding open
  26   [GitHub milestone](https://github.com/kubernetes-sigs/kubespray/milestones).
  27   That milestone remains open for the major/minor releases support lifetime,
  28   which ends once the milestone is closed. Then only a next major or minor release
  29   can be done.
  30
  31 * Kubespray major and minor releases are bound to the given `kube_version` major/minor
  32   version numbers and other components' arbitrary versions, like etcd or network plugins.
  33   Older or newer component versions are not supported and not tested for the given
  34   release (even if included in the checksum variables, like `kubeadm_checksums`).
  35
  36 * There is no unstable releases and no APIs, thus Kubespray doesn't follow
  37   [semver](https://semver.org/). Every version describes only a stable release.
  38   Breaking changes, if any introduced by changed defaults or non-contrib ansible roles'
  39   playbooks, shall be described in the release notes. Other breaking changes, if any in
  40   the contributed addons or bound versions of Kubernetes and other components, are
  41   considered out of Kubespray scope and are up to the components' teams to deal with and
  42   document.
  43
  44 * Minor releases can change components' versions, but not the major `kube_version`.
  45   Greater `kube_version` requires a new major or minor release. For example, if Kubespray v2.0.0
  46   is bound to `kube_version: 1.4.x`, `calico_version: 0.22.0`, `etcd_version: v3.0.6`,
  47   then Kubespray v2.1.0 may be bound to only minor changes to `kube_version`, like v1.5.1
  48   and *any* changes to other components, like etcd v4, or calico 1.2.3.
  49   And Kubespray v3.x.x shall be bound to `kube_version: 2.x.x` respectively.
  50
  51 ## Release note creation
  52
  53 You can create a release note with:
  54
  55 ```shell
  56 export GITHUB_TOKEN=<your-github-token>
  57 export ORG=kubernetes-sigs
  58 export REPO=kubespray
  59 release-notes --start-sha <The start commit-id> --end-sha <The end commit-id> --dependencies=false --output=/tmp/kubespray-release-note --required-author=""
  60 ```
  61
  62 If the release note file(/tmp/kubespray-release-note) contains "### Uncategorized" pull requests, those pull requests don't have a valid kind label(`kind/feature`, etc.).
  63 It is necessary to put a valid label on each pull request and run the above release-notes command again to get a better release note)
  64
  65 ## Container image creation
  66
  67 The container image `quay.io/kubespray/kubespray:vX.Y.Z` can be created from Dockerfile of the kubespray root directory:
  68
  69 ```shell
  70 cd kubespray/
  71 nerdctl build -t quay.io/kubespray/kubespray:vX.Y.Z .
  72 nerdctl push quay.io/kubespray/kubespray:vX.Y.Z
  73 ```
  74
  75 The container image `quay.io/kubespray/vagrant:vX.Y.Z` can be created from build.sh of test-infra/vagrant-docker/:
  76
  77 ```shell
  78 cd kubespray/test-infra/vagrant-docker/
  79 ./build vX.Y.Z
  80 ```
  81
  82 Please note that the above operation requires the permission to push container images into quay.io/kubespray/.
  83 If you don't have the permission, please ask it on the #kubespray-dev channel.