github.com/kaydxh/golang@v0.0.131/pkg/gocv/cgo/third_path/pybind11/docs/release.rst (about)

     1  On version numbers
     2  ^^^^^^^^^^^^^^^^^^
     3  
     4  The two version numbers (C++ and Python) must match when combined (checked when
     5  you build the PyPI package), and must be a valid `PEP 440
     6  <https://www.python.org/dev/peps/pep-0440>`_ version when combined.
     7  
     8  For example:
     9  
    10  .. code-block:: C++
    11  
    12      #define PYBIND11_VERSION_MAJOR X
    13      #define PYBIND11_VERSION_MINOR Y
    14      #define PYBIND11_VERSION_PATCH Z.dev1
    15  
    16  For beta, ``PYBIND11_VERSION_PATCH`` should be ``Z.b1``. RC's can be ``Z.rc1``.
    17  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.
    20  
    21  
    22  To release a new version of pybind11:
    23  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    24  
    25  If you don't have nox, you should either use ``pipx run nox`` instead, or use
    26  ``pipx install nox`` or ``brew install nox`` (Unix).
    27  
    28  - 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``.
    37            - Check to make sure
    38              `needs-changelog <https://github.com/pybind/pybind11/pulls?q=is%3Apr+is%3Aclosed+label%3A%22needs+changelog%22>`_
    39              issues are entered in the changelog (clear the label when done).
    40      - ``git add`` and ``git commit``, ``git push``. **Ensure CI passes**. (If it
    41        fails due to a known flake issue, either ignore or restart CI.)
    42  - Add a release branch if this is a new minor version, or update the existing release branch if it is a patch version
    43      - New branch: ``git checkout -b vX.Y``, ``git push -u origin vX.Y``
    44      - Update branch: ``git checkout vX.Y``, ``git merge <release branch>``, ``git push``
    45  - Update tags (optional; if you skip this, the GitHub release makes a
    46      non-annotated tag for you)
    47      - ``git tag -a vX.Y.Z -m 'vX.Y.Z release'``.
    48      - ``git push --tags``.
    49  - Update stable
    50      - ``git checkout stable``
    51      - ``git merge master``
    52      - ``git push``
    53  - Make a GitHub release (this shows up in the UI, sends new release
    54    notifications to users watching releases, and also uploads PyPI packages).
    55    (Note: if you do not use an existing tag, this creates a new lightweight tag
    56    for you, so you could skip the above step.)
    57      - GUI method: Under `releases <https://github.com/pybind/pybind11/releases>`_
    58        click "Draft a new release" on the far right, fill in the tag name
    59        (if you didn't tag above, it will be made here), fill in a release name
    60        like "Version X.Y.Z", and copy-and-paste the markdown-formatted (!) changelog
    61        into the description (usually ``cat docs/changelog.rst | pandoc -f rst -t gfm``).
    62        Check "pre-release" if this is a beta/RC.
    63      - CLI method: with ``gh`` installed, run ``gh release create vX.Y.Z -t "Version X.Y.Z"``
    64        If this is a pre-release, add ``-p``.
    65  
    66  - Get back to work
    67      - Make sure you are on master, not somewhere else: ``git checkout master``
    68      - Update version macros in ``include/pybind11/detail/common.h`` (set PATCH to
    69        ``0.dev1`` and increment MINOR).
    70      - Update ``_version.py`` to match
    71      - Run ``nox -s tests_packaging`` to ensure this was done correctly.
    72      - Add a spot for in-development updates in ``docs/changelog.rst``.
    73      - ``git add``, ``git commit``, ``git push``
    74  
    75  If a version branch is updated, remember to set PATCH to ``1.dev1``.
    76  
    77  If you'd like to bump homebrew, run:
    78  
    79  .. code-block:: console
    80  
    81      brew bump-formula-pr --url https://github.com/pybind/pybind11/archive/vX.Y.Z.tar.gz
    82  
    83  Conda-forge should automatically make a PR in a few hours, and automatically
    84  merge it if there are no issues.
    85  
    86  
    87  Manual packaging
    88  ^^^^^^^^^^^^^^^^
    89  
    90  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:
    91  
    92  .. code-block:: bash
    93  
    94      nox -s build
    95      twine upload dist/*
    96  
    97  This makes SDists and wheels, and the final line uploads them.