From 31ebba23d713b85d3bb098af4a81afa0e9b05654 Mon Sep 17 00:00:00 2001 From: Paul Moore Date: Sat, 12 Nov 2022 11:46:20 +0000 Subject: [PATCH] Update release docs to clarify some points --- docs/html/development/release-process.rst | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/docs/html/development/release-process.rst b/docs/html/development/release-process.rst index acff1204e7b..a9ae8465ef3 100644 --- a/docs/html/development/release-process.rst +++ b/docs/html/development/release-process.rst @@ -31,6 +31,15 @@ to need extra work before being released, the release manager always has the option to back out the partial change prior to a release. The PR can then be reworked and resubmitted for the next release. +Vendoring updates will be picked up fron the ``main`` branch, as for any other +update. Ideally, vendoring updates should be merged between releases, just like +any other change. If there are outstanding updates to vendored packages, the +release manager *may* at their discretion choose to do a vendoring update +before the release. However this is *not* a requirement and in particular, +updates to vendored packages that fix issues in pip should be merged +proactively, to ensure that they will be present in the next release. + + .. _`Deprecation Policy`: Deprecation Policy @@ -166,6 +175,11 @@ Sometimes we need to release a bugfix release of the form ``YY.N.Z+1``. In order to create one of these the changes should already be merged into the ``main`` branch. +Note that this process is only needed when there are changes on the main branch +that you do *not* want to include in the bugfix release. For a bugfix release +that will include everything that is on the ``main`` branch, the above process +for creating a new release can be used, simply changing the version number. + #. Create a new ``release/YY.N.Z+1`` branch off of the ``YY.N`` tag using the command ``git checkout -b release/YY.N.Z+1 YY.N``. #. Cherry pick the fixed commits off of the ``main`` branch, fixing any