|
| 1 | +************* |
| 2 | +Release Guide |
| 3 | +************* |
| 4 | + |
| 5 | +Welcome to the |project| Release Guide! |
| 6 | + |
| 7 | +This page contains information on how to release a new version |
| 8 | +of |project| using the automated Continuous Delivery pipeline. |
| 9 | + |
| 10 | +.. tip:: |
| 11 | + |
| 12 | + The intended audience for this document is maintainers |
| 13 | + and core contributors. |
| 14 | + |
| 15 | + |
| 16 | +Pre-release activities |
| 17 | +====================== |
| 18 | + |
| 19 | +1. Check if there are any open Pull Requests that could be |
| 20 | + desired in the upcoming release. If there are any — merge |
| 21 | + them. If some are incomplete, try to get them ready. |
| 22 | + Don't forget to review the enclosed change notes per our |
| 23 | + guidelines. |
| 24 | +2. Visually inspect the draft section of the :ref:`Change log` |
| 25 | + page. Make sure the content looks consistent, uses the same |
| 26 | + writing style, targets the end-users and adheres to our |
| 27 | + documented guidelines. |
| 28 | + Most of the changelog sections will typically use the past |
| 29 | + tense or another way to relay the effect of the changes for |
| 30 | + the users, since the previous release. |
| 31 | + It should not target core contributors as the information |
| 32 | + they are normally interested in is already present in the |
| 33 | + Git history. |
| 34 | + Update the changelog fragments if you see any problems with |
| 35 | + this changelog section. |
| 36 | +3. If you are satisfied with the above, inspect the changelog |
| 37 | + section categories in the draft. Presence of the breaking |
| 38 | + changes or features will hint you what version number |
| 39 | + segment to bump for the release. |
| 40 | + |
| 41 | +.. seealso:: |
| 42 | + |
| 43 | + :ref:`Adding change notes with your PRs` |
| 44 | + Writing beautiful changelogs for humans |
| 45 | + |
| 46 | + |
| 47 | +The release stage |
| 48 | +================= |
| 49 | + |
| 50 | +1. Open the `GitHub Actions CI/CD workflow page <GitHub Actions |
| 51 | + CI/CD workflow_>`_ in your web browser. |
| 52 | +2. Click the gray button :guilabel:`Run workflow` in the blue |
| 53 | + banner at the top of the workflow runs list. |
| 54 | +3. In the form that appears, enter the version you used in the |
| 55 | + preparation steps, into the mandatory field. Do not prepend |
| 56 | + a leading-``v``. Just use the raw version number as per |
| 57 | + :pep:`440`. |
| 58 | +4. Now, click the green button :guilabel:`Run workflow`. |
| 59 | +5. At some point, the workflow gets to the job for publishing |
| 60 | + to the "production" PyPI and stops there. You will see a |
| 61 | + banner informing you that a deployment approval is needed. |
| 62 | + You will also get an email notification with the same |
| 63 | + information and a link to the deployment approval view. |
| 64 | +6. While the normal PyPI upload hasn't happened yet, the |
| 65 | + TestPyPI one proceeds. This gives you a chance to optionally |
| 66 | + verify what got published there and decide if you want to |
| 67 | + abort the process. |
| 68 | +7. Approve the deployment and wait for the workflow to complete. |
| 69 | +8. Verify that the following things got created: |
| 70 | + |
| 71 | + - a PyPI release |
| 72 | + - a Git tag |
| 73 | + - a GitHub Releases page |
| 74 | + - a GitHub Discussions page |
| 75 | + - a release pull request on GitHub |
| 76 | + |
| 77 | +9. Merge that pull request using the natural ``git merge`` strategy |
| 78 | + avoiding squash or rebase. |
| 79 | +10. Tell everyone you released a new version of |project| :) |
| 80 | + |
| 81 | + |
| 82 | +.. _GitHub Actions CI/CD workflow: |
| 83 | + https://github.com/cherrypy/cheroot/actions/workflows/ci-cd.yml |
0 commit comments