Skip to content

Commit f3e0602

Browse files
authored
Add command to check for vX.Y.Z tag vs pybind11/_version.py consistency. (#4757)
* Add command to check for vX.Y.Z tag vs pybind11/_version.py consistency. Piggy-backing hints for converting changelog to release message. * Simpler way of double-checking version number in sources vs. git tag * Even simpler. * Fix rst rendering (hopefully) and remove stray dots. * [ci skip] Trying more to make GitHub rst renderer show this nicely. * [ci skip] Fix up RST rendering issues. Lesson learned: This is NOT GOOD: ``` - Bullet nesting level 1. - Bullet nesting level 2. ``` This is BETTER: ``` - Bullet nesting level 1. - Bullet nesting level 2. ``` Also consistently adding empty lines between bullet points, to make the .rst file easier to read. Also piggy-backing a few very minor enhancements.
1 parent 8d08dc6 commit f3e0602

File tree

1 file changed

+86
-45
lines changed

1 file changed

+86
-45
lines changed

docs/release.rst

Lines changed: 86 additions & 45 deletions
Original file line numberDiff line numberDiff line change
@@ -15,8 +15,8 @@ For example:
1515

1616
For beta, ``PYBIND11_VERSION_PATCH`` should be ``Z.b1``. RC's can be ``Z.rc1``.
1717
Always include the dot (even though PEP 440 allows it to be dropped). For a
18-
final release, this must be a simple integer. There is also a HEX version of
19-
the version just below.
18+
final release, this must be a simple integer. There is also
19+
``PYBIND11_VERSION_HEX`` just below that needs to be updated.
2020

2121

2222
To release a new version of pybind11:
@@ -26,56 +26,93 @@ If you don't have nox, you should either use ``pipx run nox`` instead, or use
2626
``pipx install nox`` or ``brew install nox`` (Unix).
2727

2828
- Update the version number
29-
- Update ``PYBIND11_VERSION_MAJOR`` etc. in
30-
``include/pybind11/detail/common.h``. PATCH should be a simple integer.
31-
- Update the version HEX just below, as well.
32-
- Update ``pybind11/_version.py`` (match above)
33-
- Run ``nox -s tests_packaging`` to ensure this was done correctly.
34-
- Ensure that all the information in ``setup.cfg`` is up-to-date, like
35-
supported Python versions.
36-
- Add release date in ``docs/changelog.rst`` and integrate the output of
37-
``nox -s make_changelog``.
38-
- Note that the ``make_changelog`` command inspects
39-
`needs changelog <https://github.com/pybind/pybind11/pulls?q=is%3Apr+is%3Aclosed+label%3A%22needs+changelog%22>`_.
40-
- Manually clear the ``needs changelog`` labels using the GitHub web
41-
interface (very easy: start by clicking the link above).
42-
- ``git add`` and ``git commit``, ``git push``. **Ensure CI passes**. (If it
43-
fails due to a known flake issue, either ignore or restart CI.)
44-
- Add a release branch if this is a new MINOR version, or update the existing release branch if it is a patch version
45-
- New branch: ``git checkout -b vX.Y``, ``git push -u origin vX.Y``
46-
- Update branch: ``git checkout vX.Y``, ``git merge <release branch>``, ``git push``
29+
30+
- Update ``PYBIND11_VERSION_MAJOR`` etc. in
31+
``include/pybind11/detail/common.h``. PATCH should be a simple integer.
32+
33+
- Update ``PYBIND11_VERSION_HEX`` just below as well.
34+
35+
- Update ``pybind11/_version.py`` (match above).
36+
37+
- Run ``nox -s tests_packaging`` to ensure this was done correctly.
38+
39+
- Ensure that all the information in ``setup.cfg`` is up-to-date, like
40+
supported Python versions.
41+
42+
- Add release date in ``docs/changelog.rst`` and integrate the output of
43+
``nox -s make_changelog``.
44+
45+
- Note that the ``make_changelog`` command inspects
46+
`needs changelog <https://github.com/pybind/pybind11/pulls?q=is%3Apr+is%3Aclosed+label%3A%22needs+changelog%22>`_.
47+
48+
- Manually clear the ``needs changelog`` labels using the GitHub web
49+
interface (very easy: start by clicking the link above).
50+
51+
- ``git add`` and ``git commit``, ``git push``. **Ensure CI passes**. (If it
52+
fails due to a known flake issue, either ignore or restart CI.)
53+
54+
- Add a release branch if this is a new MINOR version, or update the existing
55+
release branch if it is a patch version
56+
57+
- New branch: ``git checkout -b vX.Y``, ``git push -u origin vX.Y``
58+
59+
- Update branch: ``git checkout vX.Y``, ``git merge <release branch>``, ``git push``
60+
4761
- Update tags (optional; if you skip this, the GitHub release makes a
48-
non-annotated tag for you)
49-
- ``git tag -a vX.Y.Z -m 'vX.Y.Z release'``.
50-
- ``git push --tags``.
62+
non-annotated tag for you)
63+
64+
- ``git tag -a vX.Y.Z -m 'vX.Y.Z release'``
65+
66+
- ``grep ^__version__ pybind11/_version.py``
67+
68+
- Last-minute consistency check: same as tag?
69+
70+
- ``git push --tags``
71+
5172
- Update stable
52-
- ``git checkout stable``
53-
- ``git merge -X theirs vX.Y.Z``
54-
- ``git diff vX.Y.Z``
55-
- Carefully review and reconcile any diffs. There should be none.
56-
- ``git push``
73+
74+
- ``git checkout stable``
75+
76+
- ``git merge -X theirs vX.Y.Z``
77+
78+
- ``git diff vX.Y.Z``
79+
80+
- Carefully review and reconcile any diffs. There should be none.
81+
82+
- ``git push``
83+
5784
- Make a GitHub release (this shows up in the UI, sends new release
5885
notifications to users watching releases, and also uploads PyPI packages).
5986
(Note: if you do not use an existing tag, this creates a new lightweight tag
6087
for you, so you could skip the above step.)
61-
- GUI method: Under `releases <https://github.com/pybind/pybind11/releases>`_
62-
click "Draft a new release" on the far right, fill in the tag name
63-
(if you didn't tag above, it will be made here), fill in a release name
64-
like "Version X.Y.Z", and copy-and-paste the markdown-formatted (!) changelog
65-
into the description (usually ``cat docs/changelog.rst | pandoc -f rst -t gfm``).
66-
Check "pre-release" if this is a beta/RC.
67-
- CLI method: with ``gh`` installed, run ``gh release create vX.Y.Z -t "Version X.Y.Z"``
68-
If this is a pre-release, add ``-p``.
88+
89+
- GUI method: Under `releases <https://github.com/pybind/pybind11/releases>`_
90+
click "Draft a new release" on the far right, fill in the tag name
91+
(if you didn't tag above, it will be made here), fill in a release name
92+
like "Version X.Y.Z", and copy-and-paste the markdown-formatted (!) changelog
93+
into the description. You can use ``cat docs/changelog.rst | pandoc -f rst -t gfm``,
94+
then manually remove line breaks and strip links to PRs and issues,
95+
e.g. to a bare ``#1234``, without the surrounding ``<...>_`` hyperlink markup.
96+
Check "pre-release" if this is a beta/RC.
97+
98+
- CLI method: with ``gh`` installed, run ``gh release create vX.Y.Z -t "Version X.Y.Z"``
99+
If this is a pre-release, add ``-p``.
69100

70101
- Get back to work
71-
- Make sure you are on master, not somewhere else: ``git checkout master``
72-
- Update version macros in ``include/pybind11/detail/common.h`` (set PATCH to
73-
``0.dev1`` and increment MINOR).
74-
- Update ``pybind11/_version.py`` to match
75-
- Run ``nox -s tests_packaging`` to ensure this was done correctly.
76-
- If the release was a new MINOR version, add a new `IN DEVELOPMENT`
77-
section in ``docs/changelog.rst``.
78-
- ``git add``, ``git commit``, ``git push``
102+
103+
- Make sure you are on master, not somewhere else: ``git checkout master``
104+
105+
- Update version macros in ``include/pybind11/detail/common.h`` (set PATCH to
106+
``0.dev1`` and increment MINOR).
107+
108+
- Update ``pybind11/_version.py`` to match.
109+
110+
- Run ``nox -s tests_packaging`` to ensure this was done correctly.
111+
112+
- If the release was a new MINOR version, add a new ``IN DEVELOPMENT``
113+
section in ``docs/changelog.rst``.
114+
115+
- ``git add``, ``git commit``, ``git push``
79116

80117
If a version branch is updated, remember to set PATCH to ``1.dev1``.
81118

@@ -92,7 +129,11 @@ merge it if there are no issues.
92129
Manual packaging
93130
^^^^^^^^^^^^^^^^
94131

95-
If you need to manually upload releases, you can download the releases from the job artifacts and upload them with twine. You can also make the files locally (not recommended in general, as your local directory is more likely to be "dirty" and SDists love picking up random unrelated/hidden files); this is the procedure:
132+
If you need to manually upload releases, you can download the releases from
133+
the job artifacts and upload them with twine. You can also make the files
134+
locally (not recommended in general, as your local directory is more likely
135+
to be "dirty" and SDists love picking up random unrelated/hidden files);
136+
this is the procedure:
96137

97138
.. code-block:: bash
98139

0 commit comments

Comments
 (0)