Documentation: update release guide

Documentation/contributing/release.rst

@@ -14,10 +14,11 @@ This section describes the release cadence and all release related processes.
 Release Cadence
 ~~~~~~~~~~~~~~~
 
-Cilium schedules a minor release every 6 weeks. Each minor release is performed
-by incrementing the ``Y`` in the version format ``X.Y.Z``. The group of
-committers can decide to increment ``X`` instead to mark major milestones in
-which case ``Y`` is reset to 0.
+New versions of Cilium are released based on completion of feature work that has
+been scheduled for that release. Each minor release is performed by incrementing
+the ``Y`` in the version format ``X.Y.Z``. The group of committers can decide to
+increment ``X`` instead to mark major milestones in which case ``Y`` is reset to
+0.
 
 .. _stable_releases:
 
@@ -30,9 +31,7 @@ with the version ``X.Y.Z+1``. Stable releases are regularly released in high
 frequency or on demand to address major incidents.
 
 In order to guarantee stable production usage while maintaining a high release
-cadence, the following stable releases will be maintained:
-
-* Stable backports into the last two releases
+cadence, the most recent three stable releases will be maintained.
 
 Backport criteria for X.Y.Z+n
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -42,8 +41,8 @@ into ``v1.1.x`` before ``v1.2.0`` has been released:
 
 - All bugfixes
 
-Backport criteria for X.Y-1.Z
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Backport criteria for X.Y-1.Z and X.Y-2.Z
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Criteria for the inclusion into the stable release branch of the previous
 release, i.e. what goes into ``v1.0.x``, before ``v1.2.0`` has been released:
@@ -70,6 +69,11 @@ If you intent to release a new minor release, see the
 
 #. Ensure that the necessary backports have been completed and merged. See
    :ref:`backport_process`.
+
+   #. Update GitHub project and create ``vX.Y.Z+1`` project if applicable.
+   #. Update PRs / issues that were added to the ``vX.Y.Z`` project, but didn't
+      make it into this release into the ``vX.Y.Z+1`` project.
+
 #. Checkout the desired stable branch and pull it:
 
    ::
@@ -86,6 +90,11 @@ If you intent to release a new minor release, see the
 #. If this is the first release after creating a new release branch. Adjust the
    image pull policy for all ``.sed`` files in ``install/kubernetes/ciliumm/values.yaml`` from
    ``Always`` to ``IfNotPresent``.
+#. Update Helm chart documentation
+
+   #. Update versions in ``install/kubernetes/quick-install.yaml``
+   #. Update version tag in ``install/kubernetes/cilium/values.yaml``
+
 #. Update the image tag versions in the examples:
 
    ::
@@ -150,6 +159,20 @@ If you intent to release a new minor release, see the
 
        git checkout v1.0; git pull
 
+#. Build the container images and push them
+
+   ::
+
+      DOCKER_IMAGE_TAG=v1.0.3 make docker-image
+      docker push cilium/cilium:v1.0.3
+
+   .. note:
+
+      This step requires you to login with ``docker login`` first and it will
+      require your Docker hub ID to have access to the ``Cilium`` organization.
+      You can alternatively trigger a build on DockerHub directly if you have
+      credentials to do so.
+
 #. Create release tags:
 
    ::
@@ -165,6 +188,12 @@ If you intent to release a new minor release, see the
        ``x.y.z`` For more information about how ReadTheDocs does versioning, you can
        read their `Versions Documentation <https://docs.readthedocs.io/en/latest/versions.html>`_.
 
+#. Push the git release tag
+
+   ::
+
+       git push --tags
+
 #. Build the binaries and push it to the release bucket:
 
    ::
@@ -182,26 +211,6 @@ If you intent to release a new minor release, see the
        ``AWS_SECRET_ACCESS_KEY``. Ping in the ``#development`` channel on Slack
        if you have no access. It also requires the aws-cli tools to be installed.
 
-#. Build the container images and push them
-
-   ::
-
-      DOCKER_IMAGE_TAG=v1.0.3 make docker-image
-      docker push cilium/cilium:v1.0.3
-
-   .. note:
-
-      This step requires you to login with ``docker login`` first and it will
-      require your Docker hub ID to have access to the ``Cilium`` organization.
-      You can alternatively trigger a build on DockerHub directly if you have
-      credentials to do so.
-
-#. Push the git release tag
-
-   ::
-
-       git push --tags
-
 #. `Create a GitHub release <https://github.com/cilium/cilium/releases/new>`_:
 
    #. Choose the correct target branch, e.g. ``v1.0``
@@ -213,6 +222,17 @@ If you intent to release a new minor release, see the
 
       ::
 
+           Summary of Changes
+           ------------------
+
+           **Important Bug Fixes**
+
+           * Fix dropped packets upon agent bootstrap when iptables rules are installed (@ianvernon)
+
+           **Enhancements**
+
+           **Documentation**
+
            Changes
            -------
 
@@ -236,6 +256,9 @@ If you intent to release a new minor release, see the
    Please reach out on the ``#development`` channel on Slack for assistance with
    this task.
 
+#. Update the ``stable`` tags for ``cilium``, ``cilium-operator``, and
+   ``cilium-docker-plugin`` on DockerHub.
+
 #. Update the external tools and guides to point to the released Cilium version:
 
     * `kubeadm <https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/>`_