Zengtudor/pybind11
1
0
Fork 0
mirror of https://github.com/pybind/pybind11.git synced 2024-11-22 05:05:11 +00:00
Code Issues Packages Projects Releases Wiki Activity

Add command to check for vX.Y.Z tag vs pybind11/_version.py consistency. (#4757)

Browse Source 
* 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.
This commit is contained in:
Ralf W. Grosse-Kunstleve 2023-07-23 11:10:10 -07:00 committed by GitHub
parent 8d08dc64ca
commit f3e0602802
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 86 additions and 45 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

131
docs/release.rst
View File

@ -15,8 +15,8 @@ For example:
For beta, ``PYBIND11_VERSION_PATCH`` should be ``Z.b1``. RC's can be ``Z.rc1``. For beta, ``PYBIND11_VERSION_PATCH`` should be ``Z.b1``. RC's can be ``Z.rc1``.
Always include the dot (even though PEP 440 allows it to be dropped). For a Always include the dot (even though PEP 440 allows it to be dropped). For a
final release, this must be a simple integer. There is also a HEX version of final release, this must be a simple integer. There is also
the version just below. ``PYBIND11_VERSION_HEX`` just below that needs to be updated.
To release a new version of pybind11: 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
``pipx install nox`` or ``brew install nox`` (Unix). ``pipx install nox`` or ``brew install nox`` (Unix).
- Update the version number - Update the version number
- Update ``PYBIND11_VERSION_MAJOR`` etc. in
``include/pybind11/detail/common.h``. PATCH should be a simple integer. - Update ``PYBIND11_VERSION_MAJOR`` etc. in
- Update the version HEX just below, as well. ``include/pybind11/detail/common.h``. PATCH should be a simple integer.
- Update ``pybind11/_version.py`` (match above)
- Run ``nox -s tests_packaging`` to ensure this was done correctly. - Update ``PYBIND11_VERSION_HEX`` just below as well.
- Ensure that all the information in ``setup.cfg`` is up-to-date, like
supported Python versions. - Update ``pybind11/_version.py`` (match above).
- Add release date in ``docs/changelog.rst`` and integrate the output of
``nox -s make_changelog``. - Run ``nox -s tests_packaging`` to ensure this was done correctly.
- Note that the ``make_changelog`` command inspects
`needs changelog <https://github.com/pybind/pybind11/pulls?q=is%3Apr+is%3Aclosed+label%3A%22needs+changelog%22>`_. - Ensure that all the information in ``setup.cfg`` is up-to-date, like
- Manually clear the ``needs changelog`` labels using the GitHub web supported Python versions.
interface (very easy: start by clicking the link above).
- ``git add`` and ``git commit``, ``git push``. **Ensure CI passes**. (If it - Add release date in ``docs/changelog.rst`` and integrate the output of
fails due to a known flake issue, either ignore or restart CI.) ``nox -s make_changelog``.
- Add a release branch if this is a new MINOR version, or update the existing release branch if it is a patch version
- New branch: ``git checkout -b vX.Y``, ``git push -u origin vX.Y`` - Note that the ``make_changelog`` command inspects
- Update branch: ``git checkout vX.Y``, ``git merge <release branch>``, ``git push`` `needs changelog <https://github.com/pybind/pybind11/pulls?q=is%3Apr+is%3Aclosed+label%3A%22needs+changelog%22>`_.
- Manually clear the ``needs changelog`` labels using the GitHub web
interface (very easy: start by clicking the link above).
- ``git add`` and ``git commit``, ``git push``. **Ensure CI passes**. (If it
fails due to a known flake issue, either ignore or restart CI.)
- Add a release branch if this is a new MINOR version, or update the existing
release branch if it is a patch version
- New branch: ``git checkout -b vX.Y``, ``git push -u origin vX.Y``
- Update branch: ``git checkout vX.Y``, ``git merge <release branch>``, ``git push``
- Update tags (optional; if you skip this, the GitHub release makes a - Update tags (optional; if you skip this, the GitHub release makes a
non-annotated tag for you) non-annotated tag for you)
- ``git tag -a vX.Y.Z -m 'vX.Y.Z release'``.
- ``git push --tags``. - ``git tag -a vX.Y.Z -m 'vX.Y.Z release'``
- ``grep ^__version__ pybind11/_version.py``
- Last-minute consistency check: same as tag?
- ``git push --tags``
- Update stable - Update stable
- ``git checkout stable``
- ``git merge -X theirs vX.Y.Z`` - ``git checkout stable``
- ``git diff vX.Y.Z``
- Carefully review and reconcile any diffs. There should be none. - ``git merge -X theirs vX.Y.Z``
- ``git push``
- ``git diff vX.Y.Z``
- Carefully review and reconcile any diffs. There should be none.
- ``git push``
- Make a GitHub release (this shows up in the UI, sends new release - Make a GitHub release (this shows up in the UI, sends new release
notifications to users watching releases, and also uploads PyPI packages). notifications to users watching releases, and also uploads PyPI packages).
(Note: if you do not use an existing tag, this creates a new lightweight tag (Note: if you do not use an existing tag, this creates a new lightweight tag
for you, so you could skip the above step.) for you, so you could skip the above step.)
- GUI method: Under `releases <https://github.com/pybind/pybind11/releases>`_
click "Draft a new release" on the far right, fill in the tag name - GUI method: Under `releases <https://github.com/pybind/pybind11/releases>`_
(if you didn't tag above, it will be made here), fill in a release name click "Draft a new release" on the far right, fill in the tag name
like "Version X.Y.Z", and copy-and-paste the markdown-formatted (!) changelog (if you didn't tag above, it will be made here), fill in a release name
into the description (usually ``cat docs/changelog.rst | pandoc -f rst -t gfm``). like "Version X.Y.Z", and copy-and-paste the markdown-formatted (!) changelog
Check "pre-release" if this is a beta/RC. into the description. You can use ``cat docs/changelog.rst | pandoc -f rst -t gfm``,
- CLI method: with ``gh`` installed, run ``gh release create vX.Y.Z -t "Version X.Y.Z"`` then manually remove line breaks and strip links to PRs and issues,
If this is a pre-release, add ``-p``. e.g. to a bare ``#1234``, without the surrounding ``<...>_`` hyperlink markup.
Check "pre-release" if this is a beta/RC.
- CLI method: with ``gh`` installed, run ``gh release create vX.Y.Z -t "Version X.Y.Z"``
If this is a pre-release, add ``-p``.
- Get back to work - Get back to work
- Make sure you are on master, not somewhere else: ``git checkout master``
- Update version macros in ``include/pybind11/detail/common.h`` (set PATCH to - Make sure you are on master, not somewhere else: ``git checkout master``
``0.dev1`` and increment MINOR).
- Update ``pybind11/_version.py`` to match - Update version macros in ``include/pybind11/detail/common.h`` (set PATCH to
- Run ``nox -s tests_packaging`` to ensure this was done correctly. ``0.dev1`` and increment MINOR).
- If the release was a new MINOR version, add a new `IN DEVELOPMENT`
section in ``docs/changelog.rst``. - Update ``pybind11/_version.py`` to match.
- ``git add``, ``git commit``, ``git push``
- Run ``nox -s tests_packaging`` to ensure this was done correctly.
- If the release was a new MINOR version, add a new ``IN DEVELOPMENT``
section in ``docs/changelog.rst``.
- ``git add``, ``git commit``, ``git push``
If a version branch is updated, remember to set PATCH to ``1.dev1``. If a version branch is updated, remember to set PATCH to ``1.dev1``.
@ -92,7 +129,11 @@ merge it if there are no issues.
Manual packaging Manual packaging
^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^
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: 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:
.. code-block:: bash .. code-block:: bash