From 1b533049a43db4d072500784c359ad3a929f8c10 Mon Sep 17 00:00:00 2001 From: Bruno Oliveira Date: Sat, 1 Aug 2020 13:46:35 -0300 Subject: [PATCH] Add docs for releasing major/release candidates Fix #7447 --- RELEASING.rst | 71 +++++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 60 insertions(+), 11 deletions(-) diff --git a/RELEASING.rst b/RELEASING.rst index 5893987e37f..d9a5a725a84 100644 --- a/RELEASING.rst +++ b/RELEASING.rst @@ -5,24 +5,73 @@ Our current policy for releasing is to aim for a bug-fix release every few weeks is to get fixes and new features out instead of trying to cram a ton of features into a release and by consequence taking a lot of time to make a new one. +The git commands assume the following remotes are setup: + +* ``origin``: your fork of the repository +* ``upstream``: the ``pytest-dev/pytest`` official repository + Preparing: Automatic Method ~~~~~~~~~~~~~~~~~~~~~~~~~~~ We have developed an automated workflow for releases, that uses GitHub workflows and is triggered -by opening an issue or issuing a comment one. +by opening an issue. + +Bug-fix releases +^^^^^^^^^^^^^^^^ + +A bug-fix release is always done from a maintenance branch, so for example to release bug-fix +``5.1.2``, open a new issue and add this comment to the body:: + + @pytestbot please prepare release from 5.1.x + +Where ``5.1.x`` is the maintenance branch for the ``5.1`` series. + +The automated workflow will publish a PR and notify it as a comment in the issue. + +Minor releases +^^^^^^^^^^^^^^ + +1. Create a new maintenance branch from ``master``:: + + git fetch --all + git branch 5.2.x upstream/master + git push upstream 5.2.x + +2. Open a new issue and add this comment to the body:: + + @pytestbot please prepare release from 5.2.x + +The automated workflow will publish a PR and notify it as a comment in the issue. + +Major and release candidates +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +1. Create a new maintenance branch from ``master``:: + + git fetch --all + git branch 6.0.x upstream/master + git push upstream 6.0.x + +2. For a **major release**, open a new issue and add this comment in the body:: + + @pytestbot please prepare major release from master + + Or for **release candidate**, the comment must be (TODO: `#7551 `__):: -The comment must be in the form:: + @pytestbot please prepare release candidate from 6.0.x - @pytestbot please prepare release from BRANCH +The automated workflow will publish a PR and notify it as a comment in the issue. -Where ``BRANCH`` is ``master`` or one of the maintenance branches. +At this point on, this follows the same workflow as other maintenance branches: bug-fixes are merged +into ``master`` and ported back to the maintenance branch, even for release candidates. -For major releases the comment must be in the form:: +.. note:: - @pytestbot please prepare major release from master + A note about release candidates. -After that, the workflow should publish a PR and notify that it has done so as a comment -in the original issue. + During release candidates we can merge small improvements into + the maintenance branch before releasing the final major version, however we must take care + to avoid introducing big changes at this stage. Preparing: Manual Method ~~~~~~~~~~~~~~~~~~~~~~~~ @@ -34,8 +83,8 @@ Preparing: Manual Method To release a version ``MAJOR.MINOR.PATCH``, follow these steps: -#. For major and minor releases, create a new branch ``MAJOR.MINOR.x`` from the - latest ``master`` and push it to the ``pytest-dev/pytest`` repo. +#. For major and minor releases, create a new branch ``MAJOR.MINOR.x`` from + ``upstream/master`` and push it to ``upstream``. #. Create a branch ``release-MAJOR.MINOR.PATCH`` from the ``MAJOR.MINOR.x`` branch. @@ -69,7 +118,7 @@ Both automatic and manual processes described above follow the same steps from t git fetch --all --prune git checkout origin/master -b cherry-pick-release - git cherry-pick -x -m1 origin/MAJOR.MINOR.x + git cherry-pick -x -m1 upstream/MAJOR.MINOR.x #. Open a PR for ``cherry-pick-release`` and merge it once CI passes. No need to wait for approvals if there were no conflicts on the previous step.