Releasing pillow-rs

Latest release: 12.2.0-alpha.1.

Packages publish through this repository's release.yml workflow using GitHub OIDC. The release evidence keeps older measurements explicitly dated.

Artifact	Registry name	Public API
Rust core	crates.io pillow-rs	pillow_rs
Python wheels and source distribution	PyPI pillow-rs	PIL
Shared Node/browser WASM package	npm pillow-rs	pillow-rs

Publish new dependency versions from fontdone and image-slash-star first, then update pillow-rs's exact dependency versions and lockfile. Fontdone has one public Cargo crate; its C/WASM build members remain private. Image-slash-star has no Python or npm distribution.

Version policy

Use one declared version in Cargo, npm, Python, the Python runtime, and the documentation source-version field: 12.2.0-alpha.1. The base version follows the targeted Pillow version; increment the alpha.N suffix for subsequent candidates. Use beta.N, rc.N, or a stable version only when the corresponding maturity is justified. A matching Pillow version is a compatibility target, not a claim that every API is implemented.

Python tooling normalizes the declared spelling automatically for its registry metadata and archive filenames. Do not maintain a separate Python version. Release validation checks exact declarations first, then checks the normalized Python artifacts. GitHub marks candidate releases as prereleases; npm uses next until a stable release.

make release-lock-update
make release-version-check RELEASE_VERSION=v12.2.0-alpha.1

Prepare a release

1. Update authoritative package versions, exact dependency pins, lockfiles, changelog, and the source-version field in documentation.json. Keep published installation blocks on the last available registry release. Run make release-lock-update and make release-version-check with Python 3.12 to verify synchronization.
2. Run the relevant full parity, coverage, portability, package-consumer, and supply-chain checks. Preserve failures and unmeasured scope.
3. From a clean checkout, run make release-check. Inspect the crate, wheel/sdist, and packed npm contents.
4. Commit and push to main. Require successful CI for that exact commit.
5. Push a new annotated v<version> tag on the validated commit.

Tags and registry versions are immutable. Changed source or changed artifact bytes require a new version. A retry is for the same source and artifacts, not a way to replace a published package.

Publication and verification

The workflow checks tag identity, builds artifacts before authentication, validates checksums, and runs isolated consumers. Separate publishing jobs use id-token: write and the configured environments:

Registry	Workflow filename	Environment
crates.io	release.yml	crates-io
PyPI	release.yml	pypi
npm	release.yml	npm

No long-lived registry token is required. npm stable versions use latest; prereleases use next. The final GitHub release requires all registry jobs.

Verify the downloaded registry artifacts against the GitHub checksum manifest. Check registry provenance for the repository, workflow, and source identity. Install a published wheel in a fresh environment outside the checkout. The release matrix records the accepted versions and workflow runs across the three projects.

make release-tools-test
make release-status RELEASE_STATUS_ARGS='--commit <full-source-sha>'

A skipped job did not authenticate. A completed workflow is not necessarily successful. Diagnose the failing job before changing trusted-publisher settings. The recovery helper validates the original source/run and required successful jobs; it does not republish registry packages.

Platform and compatibility boundaries

Release wheels cover Linux x86-64 (manylinux 2.28), macOS ARM64, and Windows x86-64, plus an sdist for source builds. Native wheel consumers run before publication. ABI metadata and tested Python versions are separate; see installation.

Release acceptance does not complete every API, codec, GPU, or coverage goal. The maturity guide and coverage evidence preserve those boundaries.

Documentation deployment

The Documentation workflow publishes this repository's GitHub Pages site after a checked main build. It is independent of package publication: documentation changes do not require new registry versions. See the documentation checklist.

Registry references

• crates.io authentication action
• PyPI trusted publishing
• npm trusted publishing

Refresh user documentation after publication

Wait for every registry job and the GitHub release to succeed, then run:

make docs-release-refresh
make docs-release-check docs-registry-examples

Review and commit the refreshed release record and installation blocks. The Documentation workflow checks freshness after a successful tag release and on its daily schedule. Keep source-candidate versions separate from published installation versions; do not send users to a version that is still building.