benchmatrix 0.2.3__tar.gz → 0.2.4__tar.gz

{benchmatrix-0.2.3 → benchmatrix-0.2.4}/CHANGELOG.md

@@ -20,22 +20,18 @@ additional pre-1.0 compatibility expectations described in
 
 ### Security
 
-## 0.2.3 - 2026-06-23
-
-### Added
+## 0.2.4 - 2026-06-24
 
-### Changed
+### Fixed
 
-### Deprecated
+* Check out repository for context of `release` workflow
 
-### Removed
+## 0.2.3 - 2026-06-23
 
 ### Fixed
 
 * Ensure all assets uploaded to draft GitHub release
 
-### Security
-
 ## 0.2.2 - 2026-06-23
 
 ### Changed

{benchmatrix-0.2.3 → benchmatrix-0.2.4}/CITATION.cff

@@ -10,8 +10,8 @@ authors:
     given-names: "Ryan"
     email: "ryancswallace@gmail.com"
     alias: "ryancswallace"
-version: 0.2.3
-date-released: "2026-06-23"
+version: 0.2.4
+date-released: "2026-06-24"
 license: MIT
 repository-code: "https://github.com/ryancswallace/benchmatrix"
 url: "https://github.com/ryancswallace/benchmatrix"

{benchmatrix-0.2.3 → benchmatrix-0.2.4}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: benchmatrix
-Version: 0.2.3
+Version: 0.2.4
 Summary: A pytest-benchmark matrix, metadata, and JSON results layer.
 Project-URL: Homepage, https://github.com/ryancswallace/benchmatrix
 Project-URL: Changelog, https://github.com/ryancswallace/benchmatrix/blob/main/CHANGELOG.md
@@ -119,11 +119,16 @@ For local development from this repository:
 make ready
 ```
 
-To try the package from another project before the first PyPI release, install
-from GitHub:
+To install the latest release from PyPI:
 
 ```bash
-uv add "benchmatrix @ git+https://github.com/ryancswallace/benchmatrix"
+uv add benchmatrix
+```
+
+or
+
+```bash
+pip install benchmatrix
 ```
 
 ## Documentation

{benchmatrix-0.2.3 → benchmatrix-0.2.4}/README.md

@@ -88,11 +88,16 @@ For local development from this repository:
 make ready
 ```
 
-To try the package from another project before the first PyPI release, install
-from GitHub:
+To install the latest release from PyPI:
 
 ```bash
-uv add "benchmatrix @ git+https://github.com/ryancswallace/benchmatrix"
+uv add benchmatrix
+```
+
+or
+
+```bash
+pip install benchmatrix
 ```
 
 ## Documentation

benchmatrix-0.2.4/RELEASING.md

@@ -0,0 +1,28 @@
+# Release policy
+
+benchmatrix uses [Semantic Versioning](https://semver.org/).
+
+## Compatibility
+
+While the project is pre-1.0:
+
+* patch releases contain compatible fixes and documentation improvements;
+* minor releases may introduce breaking API changes;
+* breaking changes should be called out clearly in the changelog.
+
+Starting with 1.0, incompatible public API changes require a major release.
+The supported public API is the set of names exported from
+`benchmatrix.__init__`. Private modules and names beginning with an underscore
+are not covered by the compatibility guarantee.
+
+Python version support may change in a minor release before 1.0 and in a major
+release after 1.0. Dropping a Python version will be documented in advance when
+practical.
+
+Release branches are not maintained as standing support branches. The active
+support branch is `main`; temporary release or security branches may be used for
+coordination and retired after release.
+
+## Release process
+
+See the detailed operational checklist in `docs/runbooks/release.md`.

{benchmatrix-0.2.3 → benchmatrix-0.2.4}/docs/runbooks/release.md

@@ -87,21 +87,18 @@ especially the `pypi` environment and PyPI Trusted Publishing checklist.
     or remote tag, creates `v$BENCHMATRIX_RELEASE_VERSION`, and pushes it to
     `origin`.
 
-2. Wait for `.github/workflows/draft-release.yml` to create or update the draft
-    GitHub Release for `v$BENCHMATRIX_RELEASE_VERSION`. The workflow
-    validates that the tag version, package metadata, citation metadata, and
-    changelog section agree, builds the source distribution, wheel, and SBOM,
-    attaches those files to the draft release, and verifies the uploaded assets.
-3. Open the draft GitHub Release. Confirm the tag, title, notes, source
+2. Open the draft GitHub Release created by
+    `.github/workflows/draft-release.yml`. Confirm the tag, title, notes, source
     distribution, wheel, and SBOM are correct. GitHub also shows its automatic
     source code archives on the release page.
 
     If the draft workflow fails before assets are attached, rerun the
     `Draft release` workflow manually with the same `vX.Y.Z` tag after fixing
     the failure.
-4. Publish the draft GitHub Release.
-5. Watch `.github/workflows/release.yml` through the publish and verification
-    jobs.
+
+3. Publish the draft GitHub Release.
+4. Watch `.github/workflows/release.yml` through the publish and verification
+    jobs. Review and approve the `pypi` environment release if required.
 
 The draft-release workflow intentionally stops at a draft with reviewable
 package assets attached. The workflow uses `GITHUB_TOKEN`, and GitHub

{benchmatrix-0.2.3 → benchmatrix-0.2.4}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "benchmatrix"
-version = "0.2.3"
+version = "0.2.4"
 description = "A pytest-benchmark matrix, metadata, and JSON results layer."
 readme = "README.md"
 requires-python = ">=3.11,<3.15"

benchmatrix-0.2.3/RELEASING.md

@@ -1,76 +0,0 @@
-# Release policy
-
-benchmatrix uses [Semantic Versioning](https://semver.org/).
-
-## Compatibility
-
-While the project is pre-1.0:
-
-* patch releases contain compatible fixes and documentation improvements;
-* minor releases may introduce breaking API changes;
-* breaking changes should be called out clearly in the changelog.
-
-Starting with 1.0, incompatible public API changes require a major release.
-The supported public API is the set of names exported from
-`benchmatrix.__init__`. Private modules and names beginning with an underscore
-are not covered by the compatibility guarantee.
-
-Python version support may change in a minor release before 1.0 and in a major
-release after 1.0. Dropping a Python version will be documented in advance when
-practical.
-
-Release branches are not maintained as standing support branches. The active
-support branch is `main`; temporary release or security branches may be used for
-coordination and retired after release.
-
-## Release process
-
-Releases are prepared in a normal pull request, drafted automatically when a
-`vX.Y.Z` tag is pushed, and published by the GitHub Actions release workflow
-after the draft GitHub Release is reviewed and published.
-
-1. Choose the next version from the changelog and compatibility policy.
-2. Export the release version without a leading `v`:
-
-    ```bash
-    export BENCHMATRIX_RELEASE_VERSION=X.Y.Z
-    ```
-
-3. Update the `CHANGELOG.md` entries under `## Unreleased`.
-4. Prepare the release metadata, validate locally, commit the release files,
-    push the release branch, and open or reuse the standardized pull request:
-
-    ```bash
-    make release-pr-ready
-    ```
-
-    Add `RELEASE_DATE=YYYY-MM-DD` when the release date should be explicit. The
-    target runs `make release-preflight`, `make prepare-release`, `make check`,
-    and `make release-pr`. The preparation step updates `pyproject.toml`,
-    `CITATION.cff`, and `CHANGELOG.md`, updates `date-released`, creates the
-    dated changelog section, and runs `uv lock`. The pull request step creates
-    `release/v$BENCHMATRIX_RELEASE_VERSION`, commits the release metadata files,
-    pushes the branch, and opens or reuses the GitHub pull request.
-
-5. Merge the release pull request after required checks pass.
-6. Create and push the annotated release tag from the merged default branch:
-
-    ```bash
-    make release-tag
-    ```
-
-    This switches to `main`, pulls `origin/main` with `--ff-only`, validates the
-    release metadata, refuses existing tags, and pushes
-    `v$BENCHMATRIX_RELEASE_VERSION`.
-
-7. Review the draft GitHub Release created by `.github/workflows/draft-release.yml`,
-    including the attached source distribution, wheel, and SBOM assets.
-8. Publish the GitHub Release. Publishing the release triggers
-    `.github/workflows/release.yml`, which rebuilds artifacts, attaches them to
-    the GitHub Release, attests them, and publishes to PyPI through Trusted
-    Publishing.
-9. Verify the package from PyPI in a clean environment.
-10. If any post-release fix is needed, prepare a new patch release. Do not
-     replace files for an already-published PyPI version.
-
-The detailed operational checklist lives in `docs/runbooks/release.md`.