From 06e66147e68a72a1c99f1a901e676412aa8744a6 Mon Sep 17 00:00:00 2001 From: Jared O'Neal Date: Thu, 25 Jun 2026 09:04:10 -0500 Subject: [PATCH 01/12] (Issue #15) Rough draft of version info & switch Python version setup. Since we will assign a version to the repository and therefore to all the contents in the repo, we can switch the Python package versioning over to setuptools-scm so that the version of the package is automatically set based on version release tags. This has not yet been tested out. --- docs/versioning.rst | 30 ++++++++++++++++++++---------- meson.build | 12 ++++-------- openbt_pypkg/VERSION | 1 - openbt_pypkg/pyproject.toml | 14 ++++++++++++++ openbt_pypkg/setup.py | 18 ++++++++++-------- 5 files changed, 48 insertions(+), 27 deletions(-) delete mode 100644 openbt_pypkg/VERSION diff --git a/docs/versioning.rst b/docs/versioning.rst index 93fe611..956d377 100644 --- a/docs/versioning.rst +++ b/docs/versioning.rst @@ -1,13 +1,23 @@ Versioning ========== +.. _C++ command line tools: https://github.com/bandframework/OpenBT/blob/main/meson.build -.. todo:: - A versioning scheme needs to be decided on and recorded here. The following - are comments in ``meson.build`` that might help seed a conversation about - this. "The version provided here is the version of the C++ library and - command line tools. The Python package maintains a separate version. If - the C++ code is altered, then the version number here should be manually - altered and the Python package's version number altered in a similar way - since changes made to the C++ code can affect the behavior of the Python - code. If, however, only the Python code is changed, only the version of the - Python package should be altered." +This repository contains severel different, but related software products. To +reduce the complexity of managing software versions and to simplify the release +process, a single version identifier will be assigned to the entire repository +and its contents rather than designating, for example, a separate version +identifier to the `C++ command line tools`_, the Python package, and the R +package. + +Therefore, for this scheme a release might include changes to only one component +of the repository (e.g., the Python package), but the associated change in the +version identifier would be applied to all components in the repository. This +includes the unaltered R package, which has no direct relationship with the +Python package. + +For the Python package, there would be no need to upload to PyPI a "new" version +of the package when the Python package was not altered as part of the changes. +While users can access and use such "repeat" versions of the package through a +local clone, the majority of users, who we assume will install directly from +PyPI with pip install, will not be exposed to them. They will potentially see, +however, skipped versions in the package's publication history on PyPI. diff --git a/meson.build b/meson.build index ff94b94..69f2e3f 100644 --- a/meson.build +++ b/meson.build @@ -1,16 +1,12 @@ # ----- SPECIFY PROJECT # eigen dependency requires at least C++14 # -# The version provided here is the version of the C++ library and command line -# tools. The Python package maintains a separate version. If the C++ code is -# altered, then the version number here should be manually altered and the -# Python package's version number altered in a similar way since changes made to -# the C++ code can affect the behavior of the Python code. If, however, only -# the Python code is changed, only the version of the Python package should be -# altered. +# The version of the C++ command line tools is the X.Y.Z semantic version set +# into the project below. For all releases, it should be set to the tag +# assigned to the release's associated commit. project('OpenBT', 'cpp', meson_version: '>=1.6.0', - version: '1.1.0', + version: '1.2.0', license: 'MIT', license_files: 'LICENSE', default_options: [ diff --git a/openbt_pypkg/VERSION b/openbt_pypkg/VERSION deleted file mode 100644 index 781dcb0..0000000 --- a/openbt_pypkg/VERSION +++ /dev/null @@ -1 +0,0 @@ -1.1.3 diff --git a/openbt_pypkg/pyproject.toml b/openbt_pypkg/pyproject.toml index 975c9fa..f5dc7e7 100644 --- a/openbt_pypkg/pyproject.toml +++ b/openbt_pypkg/pyproject.toml @@ -1,7 +1,21 @@ +# Since the OpenBT package builds the command line tools during installation, we +# must specify outside of setup.py (i.e., here) the requirements necessary for +# build and pip to construct an isolated build system virtual environment with +# tools needed to build both the command line tools and the package. +# +# Since setting the version is also part of building distributions, we also +# include here the version determination mechanism. +# +# All other information needed to compose the package itself is in setup.py. + [build-system] requires = [ "setuptools", "ninja", "meson>=1.6.0" + "setuptools_scm[toml]>=6.0", ] build-backend = "setuptools.build_meta" + +[tool.setuptools_scm] +write_to = "src/openbt/_version.py" diff --git a/openbt_pypkg/setup.py b/openbt_pypkg/setup.py index 048cedf..66c8172 100644 --- a/openbt_pypkg/setup.py +++ b/openbt_pypkg/setup.py @@ -1,3 +1,12 @@ +# IMPORTANT +# * If necessary, please adjust pyproject.toml and GitHub actions to match +# changes to Python version here. +# * Please make sure that all dependence/version changes made here are reflected +# in tox.ini. +# +# The version is being set in _version.py by setuptools_scm (see +# pyproject.toml). No need to handle version manually here. + import os import sys import shutil @@ -23,7 +32,7 @@ # Package metadata PYTHON_REQUIRES = ">=3.10" -CODE_REQUIRES = ["numpy<=2.4.6", "matplotlib"] +CODE_REQUIRES = ["numpy", "matplotlib"] TEST_REQUIRES = ["pytest", "scipy", "pandas"] INSTALL_REQUIRES = CODE_REQUIRES + TEST_REQUIRES @@ -107,15 +116,8 @@ def readme_md(): return fptr.read() -def version(): - fname = PKG_ROOT.joinpath("VERSION") - with open(fname, "r") as fptr: - return fptr.read().strip() - - setup( name='openbt', - version=version(), author="John Yannotty", author_email="yannotty.1@buckeyemail.osu.edu", maintainer="John Yannotty", From 89d3352d334037c5088fa0b2fc3934b587a683a0 Mon Sep 17 00:00:00 2001 From: Jared O'Neal Date: Thu, 25 Jun 2026 09:31:31 -0500 Subject: [PATCH 02/12] (Issue #15) Update sdist action for release procedure. --- .github/workflows/test_py_sdist.yml | 56 ++++++++++++++++++++++++----- 1 file changed, 47 insertions(+), 9 deletions(-) diff --git a/.github/workflows/test_py_sdist.yml b/.github/workflows/test_py_sdist.yml index 5713c3e..3993566 100644 --- a/.github/workflows/test_py_sdist.yml +++ b/.github/workflows/test_py_sdist.yml @@ -11,16 +11,44 @@ on: - main jobs: + #####----- BUILD SOURCE DISTRIBUTION + # Build a single source distribution that will be used for testing across all + # different test setups. This distribution is stored as an artifact so that + # it can be manually uploaded directly to PyPI as the official (and well + # tested) release. + build: + runs-on: ubuntu-24.04 + steps: + - uses: actions/checkout@v6 + - name: Setup Python + uses: actions/setup-python@v6 + with: + python-version: "3.14" + - name: Setup base Python environment + run: $CLONE_PATH/.github/workflows/setup_base_python.sh ${{ runner.os }} + - name: Build src dist + run: | + pushd $CLONE_PATH + python -m build + ls -lart ./dist + popd + - name: Archive distributions + uses: actions/upload-artifact@v7 + with: + name: OpenBT-distribution + path: | + ${{ env.CLONE_PATH }}/dist/openbt-*.tar.gz + #####----- FULL TESTING WITHOUT COVERAGE - # Prefer full end-to-end test of local wheel built on demand rather than - # testing in local clone alone. - # - # This also confirms that the test script is functional. + # Prefer full end-to-end test of installation built from source distribution + # rather than testing in local clone alone. In particular we test this in the + # similar way to how a user might install/test it. # # Since this is the main test action with many different test setups, we # install different MPI implementations via OS package managers. The devmode # action confirms that users can install MPI implementations using PyPI/pip. test_sdist: + needs: [build] runs-on: ${{ matrix.os }} strategy: matrix: @@ -75,12 +103,22 @@ jobs: python-version: ${{ matrix.python-version }} - name: Setup Python dependencies run: $CLONE_PATH/.github/workflows/setup_base_python.sh ${{ runner.os }} + - uses: actions/download-artifact@v8 + with: + name: OpenBT-distribution + path: ${{ env.CLONE_PATH }}/dist ##-- Run full test suite - name: Run full OpenBT test suite run: | - pushd $PKG_ROOT - python -m build --sdist - python -m pip install -v dist/openbt-*.tar.gz - popd - $CLONE_PATH/tools/test_python_installation.py + distribution=$CLONE_PATH/dist/openbt-*.tar.gz + ls -la $distribution + venv=$CLONE_PATH/TestSrc + which python + python -m venv $venv + . $venv/bin/activate + which python + python -m pip install --upgrade pip + python -m pip install -v $distribution + python -m pip list + python -c "import openbt ; print(openbt.__version__) ; exit(not openbt.test())" From 70cb15ecb3a290980f1bca5dbd02494c2ee4fcb4 Mon Sep 17 00:00:00 2001 From: Jared O'Neal Date: Thu, 25 Jun 2026 09:35:34 -0500 Subject: [PATCH 03/12] (Issue #15) push to Python package folder. --- .github/workflows/test_py_sdist.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/test_py_sdist.yml b/.github/workflows/test_py_sdist.yml index 3993566..f970a35 100644 --- a/.github/workflows/test_py_sdist.yml +++ b/.github/workflows/test_py_sdist.yml @@ -28,7 +28,7 @@ jobs: run: $CLONE_PATH/.github/workflows/setup_base_python.sh ${{ runner.os }} - name: Build src dist run: | - pushd $CLONE_PATH + pushd $PKG_ROOT python -m build ls -lart ./dist popd From 2e247ce15b4d34b35811668326d2ffb810c7c706 Mon Sep 17 00:00:00 2001 From: Jared O'Neal Date: Thu, 25 Jun 2026 09:37:46 -0500 Subject: [PATCH 04/12] (Issue #15) Need a comma --- openbt_pypkg/pyproject.toml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/openbt_pypkg/pyproject.toml b/openbt_pypkg/pyproject.toml index f5dc7e7..967da9d 100644 --- a/openbt_pypkg/pyproject.toml +++ b/openbt_pypkg/pyproject.toml @@ -12,8 +12,8 @@ requires = [ "setuptools", "ninja", - "meson>=1.6.0" - "setuptools_scm[toml]>=6.0", + "meson>=1.6.0", + "setuptools_scm[toml]>=6.0" ] build-backend = "setuptools.build_meta" From 678088403425ef00db003d0cb752be2d708bbf6c Mon Sep 17 00:00:00 2001 From: Jared O'Neal Date: Thu, 25 Jun 2026 09:43:20 -0500 Subject: [PATCH 05/12] (Issue #15) Help setuptools-scm orient itself. --- openbt_pypkg/pyproject.toml | 1 + 1 file changed, 1 insertion(+) diff --git a/openbt_pypkg/pyproject.toml b/openbt_pypkg/pyproject.toml index 967da9d..4397305 100644 --- a/openbt_pypkg/pyproject.toml +++ b/openbt_pypkg/pyproject.toml @@ -18,4 +18,5 @@ requires = [ build-backend = "setuptools.build_meta" [tool.setuptools_scm] +root = ".." write_to = "src/openbt/_version.py" From de670fa90c112adb7006da2267ae8c2fb2b6b807 Mon Sep 17 00:00:00 2001 From: Jared O'Neal Date: Thu, 25 Jun 2026 09:52:49 -0500 Subject: [PATCH 06/12] (Issue #15) Ensure sdist is minimal and clean. --- .github/workflows/test_py_sdist.yml | 2 +- openbt_pypkg/MANIFEST.in | 5 +++++ openbt_pypkg/pyproject.toml | 2 +- 3 files changed, 7 insertions(+), 2 deletions(-) diff --git a/.github/workflows/test_py_sdist.yml b/.github/workflows/test_py_sdist.yml index f970a35..b59844f 100644 --- a/.github/workflows/test_py_sdist.yml +++ b/.github/workflows/test_py_sdist.yml @@ -29,7 +29,7 @@ jobs: - name: Build src dist run: | pushd $PKG_ROOT - python -m build + python -m build --sdist ls -lart ./dist popd - name: Archive distributions diff --git a/openbt_pypkg/MANIFEST.in b/openbt_pypkg/MANIFEST.in index 762761c..3a00cd5 100644 --- a/openbt_pypkg/MANIFEST.in +++ b/openbt_pypkg/MANIFEST.in @@ -1,4 +1,9 @@ include LICENSE VERSION +exclude .flake8 .coveragerc +exclude tox.ini +prune src/openbt/bin +prune src/openbt/lib +prune src/openbt/include include cpp/LICENSE include cpp/meson.build include cpp/meson.options diff --git a/openbt_pypkg/pyproject.toml b/openbt_pypkg/pyproject.toml index 4397305..8a4e5d4 100644 --- a/openbt_pypkg/pyproject.toml +++ b/openbt_pypkg/pyproject.toml @@ -19,4 +19,4 @@ build-backend = "setuptools.build_meta" [tool.setuptools_scm] root = ".." -write_to = "src/openbt/_version.py" +write_to = "openbt_pypkg/src/openbt/_version.py" From e699a2809af9c97fe6705234082f7379a09283c1 Mon Sep 17 00:00:00 2001 From: Jared O'Neal Date: Thu, 25 Jun 2026 09:56:17 -0500 Subject: [PATCH 07/12] (Issue #15) Still compensating for different package location. --- .github/workflows/test_py_sdist.yml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/.github/workflows/test_py_sdist.yml b/.github/workflows/test_py_sdist.yml index b59844f..2d98a9d 100644 --- a/.github/workflows/test_py_sdist.yml +++ b/.github/workflows/test_py_sdist.yml @@ -37,7 +37,7 @@ jobs: with: name: OpenBT-distribution path: | - ${{ env.CLONE_PATH }}/dist/openbt-*.tar.gz + ${{ env.PKG_ROOT }}/dist/openbt-*.tar.gz #####----- FULL TESTING WITHOUT COVERAGE # Prefer full end-to-end test of installation built from source distribution @@ -106,12 +106,12 @@ jobs: - uses: actions/download-artifact@v8 with: name: OpenBT-distribution - path: ${{ env.CLONE_PATH }}/dist + path: ${{ env.PKG_ROOT }}/dist ##-- Run full test suite - name: Run full OpenBT test suite run: | - distribution=$CLONE_PATH/dist/openbt-*.tar.gz + distribution=$PKG_ROOT/dist/openbt-*.tar.gz ls -la $distribution venv=$CLONE_PATH/TestSrc which python From f713f0ae81e977d545eeae84efa63609912ecfe1 Mon Sep 17 00:00:00 2001 From: Jared O'Neal Date: Thu, 25 Jun 2026 12:20:09 -0500 Subject: [PATCH 08/12] (Issue #15) Grow the docs. Also updated the source distribution action so that hopefully it will be run on release events since that will create a source distribution with the correct version. --- .github/workflows/test_py_sdist.yml | 5 + .gitignore | 1 + docs/index.rst | 1 + docs/release_procedure.rst | 162 ++++++++++++++++++++++++++++ docs/versioning.rst | 42 +++++++- 5 files changed, 207 insertions(+), 4 deletions(-) create mode 100644 docs/release_procedure.rst diff --git a/.github/workflows/test_py_sdist.yml b/.github/workflows/test_py_sdist.yml index 2d98a9d..3084cba 100644 --- a/.github/workflows/test_py_sdist.yml +++ b/.github/workflows/test_py_sdist.yml @@ -9,6 +9,11 @@ on: pull_request: branches: - main + release: + # Have this run on release so that it produces a Python source distribution + # whose version is correctly set to the release's vX.Y.Z tag. + branches: [main] + types: [published] jobs: #####----- BUILD SOURCE DISTRIBUTION diff --git a/.gitignore b/.gitignore index 5b98333..11f91bc 100644 --- a/.gitignore +++ b/.gitignore @@ -33,6 +33,7 @@ openbt_pypkg/.coverage_openbt openbt_pypkg/coverage.xml openbt_pypkg/htmlcov openbt_pypkg/src/openbt.egg-info +openbt_pypkg/src/openbt/_version.py # Other files .DS_Store diff --git a/docs/index.rst b/docs/index.rst index a270b4c..31061a8 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -35,4 +35,5 @@ This package is being developed as part of |band| `framework git_workflow documentation versioning + release_procedure tox_usage diff --git a/docs/release_procedure.rst b/docs/release_procedure.rst new file mode 100644 index 0000000..a6c1f12 --- /dev/null +++ b/docs/release_procedure.rst @@ -0,0 +1,162 @@ +Release Procedure +================= + +Prerelease actions +------------------ +.. _Python version support: https://devguide.python.org/versions +.. _Numpy version support: https://numpy.org/neps/nep-0029-deprecation_policy.html#support-table +.. _Scipy version support: https://docs.scipy.org/doc/scipy/dev/core-dev/index.html#building-binary-installers +.. _Supported action runner images: https://github.com/actions/runner-images +.. _specification file: https://github.com/bandframework/OpenBT/blob/main/meson.build + +Seed the release process + +* Determine the new version string needed for the release in accordance with the + contents of :numref:`versioning`. +* Create a new release "super" issue (|ie| a GitHub issue that simply contains + a list of links to other GitHub issues). + + * Content could be seeded from previous release's issue + * All gatekeepers should converge on set of high-level tasks/goals for release + * Create an issue for each approved task and add link to issue in the + release "super" issue + * As work proceeds, a link to each PR can be placed next to its associated + Issue's link + +* Optionally, create a post-release issue to group together all new issues + created during this prerelease/release work that won't be dealt with during + the release, but that should be dealt with shortly after the release to + maintain inertia and capitalize on the recent work/experience. + + * This should be maintained up-to-date. Tasks that ultimately can be put off + until later can be moved out of this issue. Issues that will no longer be + dealt with as part of the review can be transferred from the release to + post-release issue. + +* Notify BAND framework team that a new version will be released to determine + what steps will need to be made, if any, within the framework once the release + is finalized. + +Once all tasks have been executed + +* Check if a new version of the Eigen package is available through the Meson + build system's wrapdb and assess if the new version should be adopted and + tested. +* Review and update all metadata in ``setup.py`` +* Review all external dependencies and their stated versions to see if they need + updating and address on a feature branch + + * `Python version support`_ + * `Numpy version support`_ + * `Scipy version support`_ + * Confirm that all version information specified in ``setup.py``, + ``pyproject.toml``, ``tox.ini``, and GitHub actions are consistent. + +* Modernize all repository actions in accord with changes to supported versions + and updated GH action infrastructure + + * `Supported action runner images`_ + * Are their test setups that are presently excluded and that should be added + back in? + +* Review README including badges for necessary cleaning/updates + + * New references? + * Update citation? + * Check links + +* Review all documentation associated with the repository including examples to + determine if any updates still need to be made and address on a feature branch + + * Sphinx/RTD User and Developer Guides + +* Confirm continued adherence to all binding requirements (e.g., BAND SDK) +* Set the version of the C++ command line tools in their Meson build system + `specification file`_ to the correct version string determined earlier + +Release actions +--------------- +When a particular commit on ``main`` is deemed a release, + +#. Confirm that all actions run on the proposed commit and pass +#. Perform any review of the action logs deemed necessary based on the changes + included in the release +#. Perform any review of the artifacts created by the actions deemed necessary + based on the changes included in the release +#. Create and push a tag ``vX.Y.Z`` on ``main`` corresponding to the release. + This will trigger the ``test_py_sdist`` GitHub action, which builds the + source distribution with the correct version and tests it. +#. Confirm that the action passed with no errors or warnings. Review the + action's log. +#. Create a **draft** release with the correct tag ``vX.Y.Z`` and indicate if + the release included changes to the C++ command line tools, the Python + package, or both. +#. Carry out all necessary checks for the different software products (see + below). +#. Change the state of the release to **publish** once all checks are finished + and the release is ready for publishing to PyPI. + +Command line tools +^^^^^^^^^^^^^^^^^^ +#. Gatekeepers to follow installation guide to install and test the command line + tools. This should include a review of the build logs. + +Python package +^^^^^^^^^^^^^^ +.. _twine instructions: https://twine.readthedocs.io/en/stable/index.html#using-twine + +.. note:: + Since PyPI does not permit the uploading of a revised version to overwrite a + previous upload of that same version, these steps should like be done only + **after** having carried out the sanity checks for all other software + products. + +If the changes in the release do **not** include changes to the C++ command line +tools or the Python package, then no actions are needed. In particular, we do +**not** upload to PyPI the source distributions created with this new versioned +release. + +Otherwise, + +#. Download the source distribution artifact from the ``test_py_sdist`` action + and confirm that filename contains the desired version indicator. +#. Decompress the source distribution with ``tar xvfz`` and confirm correct, + minimal contents including the presence of the LICENSE file. + + * One side effect of the use of ``setuptools-scm`` is that by default it + includes in the distribution all files located within ``openbt_pypkg``. + However, many files and folders in that space do **not** need to be + distributed (|eg| Flake8 configuration files and OpenBT command line tools + installed in ``src/openbt/bin``). This is what "minimal" means above. + Files and folders that should not be included in the distribution are + specified in ``MANIFEST.in``. + * Review the metadata to ensure correct and complete. This should include + the correct specification of the new version indicator. + +#. Gatekeepers to follow installation guide to install and test the Python + package |via| all provided mechanisms as well as with the release's source + distribution. +#. Upload the distributions to the PyPI server, review the package's webpage on + PyPI, and repeat tests on a variety of systems using a variety of Python + versions and MPI implementations. +#. Create a clean virtual environment, update |pip|, and install ``twine``. +#. Use that venv to publish the distributions to PyPI following the + `twine instructions`_. Note that to upload distributions, you will need to + know either your username and password or have an API token that you can + generate on the PyPI website under your personal settings. +#. Review the package's webpage on PyPI. +#. In a clean virtual environment, follow the installation guide for installing + from |pip| and to test the installation + +.. todo:: + * Should Sphinx docs only be built for public release of RTD on releases or + on every commit on ``main``? + +Post-release +------------ +* Carry out all necessary tasks to integrate the release within the BAND + framework. +* Update this document based on lessons learned. +* Review all open issues and pull requests. Comment and close where possible. + Clean-up the post-release issue in preparation for carrying out the work that + it requests. diff --git a/docs/versioning.rst b/docs/versioning.rst index 956d377..b9dee5c 100644 --- a/docs/versioning.rst +++ b/docs/versioning.rst @@ -1,13 +1,12 @@ +.. _versioning: + Versioning ========== -.. _C++ command line tools: https://github.com/bandframework/OpenBT/blob/main/meson.build - This repository contains severel different, but related software products. To reduce the complexity of managing software versions and to simplify the release process, a single version identifier will be assigned to the entire repository and its contents rather than designating, for example, a separate version -identifier to the `C++ command line tools`_, the Python package, and the R -package. +identifier to the C++ command line tools, the Python package, and the R package. Therefore, for this scheme a release might include changes to only one component of the repository (e.g., the Python package), but the associated change in the @@ -21,3 +20,38 @@ While users can access and use such "repeat" versions of the package through a local clone, the majority of users, who we assume will install directly from PyPI with pip install, will not be exposed to them. They will potentially see, however, skipped versions in the package's publication history on PyPI. + +Versioning rules +---------------- + +* Only commits on the ``main`` branch can be considered for release +* Version identifiers are strings that adhere to semantic versioning, and the + version increment made will be made based on the most significant change or + addition made across all software products +* Release commits will be tagged using ``vX.Y.Z`` in accordance with + ``setuptools_scm`` requirements to allow for automatic versioning of the + Python package +* Each release should be made publicly through the repository's release + facilities as offered by GitHub + +C++ command line tools +---------------------- +.. _specification file: https://github.com/bandframework/OpenBT/blob/main/meson.build + +The version of the C++ command line tools is specified in the tools' Meson build +system `specification file`_. If a change is made in the tools or its build +system that requires a new version, it is a natural consequence that all derived +software products (|eg| the Python package) have their version number altered in +a consistent way. + +Based on our versioning scheme, the tools' version will be updated even if a +change is made only in one or more of the derived software products. + +Python package +-------------- +We prefer to adhere to the standard versioning practices of the Python +community, which drives the versioning scheme of the whole repository. The +version of the Python package is managed automatically by the use the +``setuptools_scm`` in ``pyproject.toml``. The version identifier for the source +distribution constructed from a tagged commit will automatically be set to the +tag's name. Only these distributions should be distributed officially. From e07ef3580a457f1f606849def0174991bcf3f7bb Mon Sep 17 00:00:00 2001 From: Jared O'Neal Date: Thu, 25 Jun 2026 14:16:37 -0500 Subject: [PATCH 09/12] (Issue #15) Clean as part of PR review --- docs/release_procedure.rst | 30 +++++++++++++----------------- docs/versioning.rst | 18 +++++++++--------- openbt_pypkg/MANIFEST.in | 2 ++ 3 files changed, 24 insertions(+), 26 deletions(-) diff --git a/docs/release_procedure.rst b/docs/release_procedure.rst index a6c1f12..21c0407 100644 --- a/docs/release_procedure.rst +++ b/docs/release_procedure.rst @@ -1,8 +1,8 @@ Release Procedure ================= -Prerelease actions ------------------- +Pre-release actions +------------------- .. _Python version support: https://devguide.python.org/versions .. _Numpy version support: https://numpy.org/neps/nep-0029-deprecation_policy.html#support-table .. _Scipy version support: https://docs.scipy.org/doc/scipy/dev/core-dev/index.html#building-binary-installers @@ -11,8 +11,8 @@ Prerelease actions Seed the release process -* Determine the new version string needed for the release in accordance with the - contents of :numref:`versioning`. +* Determine the new version string ``vX.Y.Z`` needed for the release in + accordance with the contents of :numref:`versioning`. * Create a new release "super" issue (|ie| a GitHub issue that simply contains a list of links to other GitHub issues). @@ -70,7 +70,7 @@ Once all tasks have been executed * Sphinx/RTD User and Developer Guides -* Confirm continued adherence to all binding requirements (e.g., BAND SDK) +* Confirm continued adherence to all binding requirements (|eg| BAND SDK) * Set the version of the C++ command line tools in their Meson build system `specification file`_ to the correct version string determined earlier @@ -83,9 +83,9 @@ When a particular commit on ``main`` is deemed a release, included in the release #. Perform any review of the artifacts created by the actions deemed necessary based on the changes included in the release -#. Create and push a tag ``vX.Y.Z`` on ``main`` corresponding to the release. - This will trigger the ``test_py_sdist`` GitHub action, which builds the - source distribution with the correct version and tests it. +#. Tag the release commit with the name ``vX.Y.Z`` and push. This will trigger + the ``test_py_sdist`` GitHub action, which builds the source distribution + with the correct version indicator and tests it. #. Confirm that the action passed with no errors or warnings. Review the action's log. #. Create a **draft** release with the correct tag ``vX.Y.Z`` and indicate if @@ -93,13 +93,13 @@ When a particular commit on ``main`` is deemed a release, package, or both. #. Carry out all necessary checks for the different software products (see below). -#. Change the state of the release to **publish** once all checks are finished - and the release is ready for publishing to PyPI. +#. Change the state of the release to **publish**. Command line tools ^^^^^^^^^^^^^^^^^^ #. Gatekeepers to follow installation guide to install and test the command line - tools. This should include a review of the build logs. + tools. This should include a review of the build logs and confirming correct + logging of the new release version indicator. Python package ^^^^^^^^^^^^^^ @@ -107,7 +107,7 @@ Python package .. note:: Since PyPI does not permit the uploading of a revised version to overwrite a - previous upload of that same version, these steps should like be done only + previous upload of that same version, these steps should likely be done only **after** having carried out the sanity checks for all other software products. @@ -140,7 +140,7 @@ Otherwise, PyPI, and repeat tests on a variety of systems using a variety of Python versions and MPI implementations. #. Create a clean virtual environment, update |pip|, and install ``twine``. -#. Use that venv to publish the distributions to PyPI following the +#. Use that venv to publish the source distribution to PyPI following the `twine instructions`_. Note that to upload distributions, you will need to know either your username and password or have an API token that you can generate on the PyPI website under your personal settings. @@ -148,10 +148,6 @@ Otherwise, #. In a clean virtual environment, follow the installation guide for installing from |pip| and to test the installation -.. todo:: - * Should Sphinx docs only be built for public release of RTD on releases or - on every commit on ``main``? - Post-release ------------ * Carry out all necessary tasks to integrate the release within the BAND diff --git a/docs/versioning.rst b/docs/versioning.rst index b9dee5c..1eca7a8 100644 --- a/docs/versioning.rst +++ b/docs/versioning.rst @@ -2,24 +2,24 @@ Versioning ========== -This repository contains severel different, but related software products. To +This repository contains several different, but related software products. To reduce the complexity of managing software versions and to simplify the release process, a single version identifier will be assigned to the entire repository and its contents rather than designating, for example, a separate version identifier to the C++ command line tools, the Python package, and the R package. Therefore, for this scheme a release might include changes to only one component -of the repository (e.g., the Python package), but the associated change in the +of the repository (|eg| the Python package), but the associated change in the version identifier would be applied to all components in the repository. This -includes the unaltered R package, which has no direct relationship with the +would include the unaltered R package, which has no direct relationship with the Python package. For the Python package, there would be no need to upload to PyPI a "new" version of the package when the Python package was not altered as part of the changes. While users can access and use such "repeat" versions of the package through a local clone, the majority of users, who we assume will install directly from -PyPI with pip install, will not be exposed to them. They will potentially see, -however, skipped versions in the package's publication history on PyPI. +PyPI with ``pip install``, will not be exposed to them. They will potentially +see, however, skipped versions in the package's publication history on PyPI. Versioning rules ---------------- @@ -27,9 +27,9 @@ Versioning rules * Only commits on the ``main`` branch can be considered for release * Version identifiers are strings that adhere to semantic versioning, and the version increment made will be made based on the most significant change or - addition made across all software products + addition made across all software products in the repository * Release commits will be tagged using ``vX.Y.Z`` in accordance with - ``setuptools_scm`` requirements to allow for automatic versioning of the + ``setuptools-scm`` requirements to allow for automatic versioning of the Python package * Each release should be made publicly through the repository's release facilities as offered by GitHub @@ -51,7 +51,7 @@ Python package -------------- We prefer to adhere to the standard versioning practices of the Python community, which drives the versioning scheme of the whole repository. The -version of the Python package is managed automatically by the use the -``setuptools_scm`` in ``pyproject.toml``. The version identifier for the source +version of the Python package is managed automatically by the configuration of +``setuptools-scm`` in ``pyproject.toml``. The version identifier for the source distribution constructed from a tagged commit will automatically be set to the tag's name. Only these distributions should be distributed officially. diff --git a/openbt_pypkg/MANIFEST.in b/openbt_pypkg/MANIFEST.in index 3a00cd5..9f8c6e7 100644 --- a/openbt_pypkg/MANIFEST.in +++ b/openbt_pypkg/MANIFEST.in @@ -10,3 +10,5 @@ include cpp/meson.options include cpp/includes/*.h include cpp/src/*.cpp include cpp/subprojects/*.wrap +exclude cpp/subprojects/README.md +exclude cpp/subprojects/wrapdb.json From 1df26d9b80ebac6cb120b480342565d810aea6c3 Mon Sep 17 00:00:00 2001 From: Jared O'Neal Date: Thu, 25 Jun 2026 14:52:08 -0500 Subject: [PATCH 10/12] (Issue #15) Cleaning some more as part of review. --- docs/release_procedure.rst | 2 ++ docs/versioning.rst | 7 ++++--- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/docs/release_procedure.rst b/docs/release_procedure.rst index 21c0407..0ddc643 100644 --- a/docs/release_procedure.rst +++ b/docs/release_procedure.rst @@ -6,6 +6,7 @@ Pre-release actions .. _Python version support: https://devguide.python.org/versions .. _Numpy version support: https://numpy.org/neps/nep-0029-deprecation_policy.html#support-table .. _Scipy version support: https://docs.scipy.org/doc/scipy/dev/core-dev/index.html#building-binary-installers +.. _scientific Python support: https://scientific-python.org/specs/spec-0000 .. _Supported action runner images: https://github.com/actions/runner-images .. _specification file: https://github.com/bandframework/OpenBT/blob/main/meson.build @@ -49,6 +50,7 @@ Once all tasks have been executed * `Python version support`_ * `Numpy version support`_ * `Scipy version support`_ + * `scientific Python support`_ * Confirm that all version information specified in ``setup.py``, ``pyproject.toml``, ``tox.ini``, and GitHub actions are consistent. diff --git a/docs/versioning.rst b/docs/versioning.rst index 1eca7a8..60d5631 100644 --- a/docs/versioning.rst +++ b/docs/versioning.rst @@ -23,11 +23,12 @@ see, however, skipped versions in the package's publication history on PyPI. Versioning rules ---------------- +.. _SemVer: https://semver.org * Only commits on the ``main`` branch can be considered for release -* Version identifiers are strings that adhere to semantic versioning, and the - version increment made will be made based on the most significant change or - addition made across all software products in the repository +* Version identifiers are strings that adhere to semantic versioning (SemVer_), + and the version increment made will be made based on the most significant + change or addition made across all software products in the repository * Release commits will be tagged using ``vX.Y.Z`` in accordance with ``setuptools-scm`` requirements to allow for automatic versioning of the Python package From 86f98c870782d9e8b73c90346213cd334f321821 Mon Sep 17 00:00:00 2001 From: Jared O'Neal Date: Thu, 25 Jun 2026 15:14:11 -0500 Subject: [PATCH 11/12] (Issue #15) Hopefully final cleaning as part of PR review. --- docs/release_procedure.rst | 17 +++++++---------- docs/versioning.rst | 13 +++++++------ 2 files changed, 14 insertions(+), 16 deletions(-) diff --git a/docs/release_procedure.rst b/docs/release_procedure.rst index 0ddc643..9688c63 100644 --- a/docs/release_procedure.rst +++ b/docs/release_procedure.rst @@ -41,8 +41,8 @@ Seed the release process Once all tasks have been executed * Check if a new version of the Eigen package is available through the Meson - build system's wrapdb and assess if the new version should be adopted and - tested. + build system's wrapdb facility and assess if the new version should be adopted + and tested. * Review and update all metadata in ``setup.py`` * Review all external dependencies and their stated versions to see if they need updating and address on a feature branch @@ -52,13 +52,13 @@ Once all tasks have been executed * `Scipy version support`_ * `scientific Python support`_ * Confirm that all version information specified in ``setup.py``, - ``pyproject.toml``, ``tox.ini``, and GitHub actions are consistent. + ``pyproject.toml``, and ``tox.ini``. * Modernize all repository actions in accord with changes to supported versions and updated GH action infrastructure * `Supported action runner images`_ - * Are their test setups that are presently excluded and that should be added + * Are there test setups that are presently excluded and that should be added back in? * Review README including badges for necessary cleaning/updates @@ -129,18 +129,15 @@ Otherwise, includes in the distribution all files located within ``openbt_pypkg``. However, many files and folders in that space do **not** need to be distributed (|eg| Flake8 configuration files and OpenBT command line tools - installed in ``src/openbt/bin``). This is what "minimal" means above. - Files and folders that should not be included in the distribution are - specified in ``MANIFEST.in``. + installed during development in ``src/openbt/bin``). This is what + "minimal" means above. Files and folders that should not be included in + the distribution are specified in ``MANIFEST.in``. * Review the metadata to ensure correct and complete. This should include the correct specification of the new version indicator. #. Gatekeepers to follow installation guide to install and test the Python package |via| all provided mechanisms as well as with the release's source distribution. -#. Upload the distributions to the PyPI server, review the package's webpage on - PyPI, and repeat tests on a variety of systems using a variety of Python - versions and MPI implementations. #. Create a clean virtual environment, update |pip|, and install ``twine``. #. Use that venv to publish the source distribution to PyPI following the `twine instructions`_. Note that to upload distributions, you will need to diff --git a/docs/versioning.rst b/docs/versioning.rst index 60d5631..65c4e07 100644 --- a/docs/versioning.rst +++ b/docs/versioning.rst @@ -15,11 +15,12 @@ would include the unaltered R package, which has no direct relationship with the Python package. For the Python package, there would be no need to upload to PyPI a "new" version -of the package when the Python package was not altered as part of the changes. -While users can access and use such "repeat" versions of the package through a -local clone, the majority of users, who we assume will install directly from -PyPI with ``pip install``, will not be exposed to them. They will potentially -see, however, skipped versions in the package's publication history on PyPI. +of the package when neither the C++ command line tools nor the Python package +were altered as part of the changes. While users can access and use such +"repeat" versions of the package through a local clone, the majority of users, +who we assume will install directly from PyPI with ``pip install``, will not be +exposed to them. They will potentially see, however, skipped versions in the +package's release history on PyPI. Versioning rules ---------------- @@ -33,7 +34,7 @@ Versioning rules ``setuptools-scm`` requirements to allow for automatic versioning of the Python package * Each release should be made publicly through the repository's release - facilities as offered by GitHub + facilities as offered by GitHub's web interface C++ command line tools ---------------------- From 0567794406439be122616f3c2f4b9620a6ab8928 Mon Sep 17 00:00:00 2001 From: Jared O'Neal Date: Thu, 25 Jun 2026 15:39:35 -0500 Subject: [PATCH 12/12] (Issue #15) Continue polishing logic and explicit language. --- docs/release_procedure.rst | 35 ++++++++++++++++++----------------- 1 file changed, 18 insertions(+), 17 deletions(-) diff --git a/docs/release_procedure.rst b/docs/release_procedure.rst index 9688c63..8adaee2 100644 --- a/docs/release_procedure.rst +++ b/docs/release_procedure.rst @@ -12,7 +12,7 @@ Pre-release actions Seed the release process -* Determine the new version string ``vX.Y.Z`` needed for the release in +* Determine the new version identifier ``vX.Y.Z`` needed for the release in accordance with the contents of :numref:`versioning`. * Create a new release "super" issue (|ie| a GitHub issue that simply contains a list of links to other GitHub issues). @@ -22,7 +22,7 @@ Seed the release process * Create an issue for each approved task and add link to issue in the release "super" issue * As work proceeds, a link to each PR can be placed next to its associated - Issue's link + issue's link * Optionally, create a post-release issue to group together all new issues created during this prerelease/release work that won't be dealt with during @@ -52,7 +52,7 @@ Once all tasks have been executed * `Scipy version support`_ * `scientific Python support`_ * Confirm that all version information specified in ``setup.py``, - ``pyproject.toml``, and ``tox.ini``. + ``pyproject.toml``, and ``tox.ini`` are consistent * Modernize all repository actions in accord with changes to supported versions and updated GH action infrastructure @@ -74,20 +74,20 @@ Once all tasks have been executed * Confirm continued adherence to all binding requirements (|eg| BAND SDK) * Set the version of the C++ command line tools in their Meson build system - `specification file`_ to the correct version string determined earlier + `specification file`_ to the correct version identifier determined earlier Release actions --------------- -When a particular commit on ``main`` is deemed a release, +When a particular commit on ``main`` is to be deemed a release, -#. Confirm that all actions run on the proposed commit and pass +#. Confirm that all actions ran successfully on the proposed commit #. Perform any review of the action logs deemed necessary based on the changes included in the release #. Perform any review of the artifacts created by the actions deemed necessary based on the changes included in the release #. Tag the release commit with the name ``vX.Y.Z`` and push. This will trigger the ``test_py_sdist`` GitHub action, which builds the source distribution - with the correct version indicator and tests it. + with the correct version identifier and tests it. #. Confirm that the action passed with no errors or warnings. Review the action's log. #. Create a **draft** release with the correct tag ``vX.Y.Z`` and indicate if @@ -101,7 +101,7 @@ Command line tools ^^^^^^^^^^^^^^^^^^ #. Gatekeepers to follow installation guide to install and test the command line tools. This should include a review of the build logs and confirming correct - logging of the new release version indicator. + logging of the new release version identifier. Python package ^^^^^^^^^^^^^^ @@ -121,7 +121,7 @@ release. Otherwise, #. Download the source distribution artifact from the ``test_py_sdist`` action - and confirm that filename contains the desired version indicator. + and confirm that filename contains the desired version identifier. #. Decompress the source distribution with ``tar xvfz`` and confirm correct, minimal contents including the presence of the LICENSE file. @@ -133,22 +133,23 @@ Otherwise, "minimal" means above. Files and folders that should not be included in the distribution are specified in ``MANIFEST.in``. * Review the metadata to ensure correct and complete. This should include - the correct specification of the new version indicator. + the correct specification of the new version identifier. #. Gatekeepers to follow installation guide to install and test the Python - package |via| all provided mechanisms as well as with the release's source + package in clean virtual environments |via| all provided mechanisms (aside + from ``pip install``) as well as by installing from the release's source distribution. #. Create a clean virtual environment, update |pip|, and install ``twine``. -#. Use that venv to publish the source distribution to PyPI following the - `twine instructions`_. Note that to upload distributions, you will need to - know either your username and password or have an API token that you can - generate on the PyPI website under your personal settings. +#. Use that venv to publish the downloaded source distribution to PyPI following + the `twine instructions`_. Note that to upload the distribution, you will + need to know either your username and password or have an API token that you + can generate on the PyPI website under your personal settings. #. Review the package's webpage on PyPI. #. In a clean virtual environment, follow the installation guide for installing from |pip| and to test the installation -Post-release ------------- +Post-release actions +-------------------- * Carry out all necessary tasks to integrate the release within the BAND framework. * Update this document based on lessons learned.