Skip to content

feat(release): automate release preparation - #348

Open
Mattsface wants to merge 1 commit into
mainfrom
feature/issue-345-release-automation
Open

Mattsface wants to merge 1 commit into
mainfrom
feature/issue-345-release-automation

Conversation

@Mattsface

Copy link
Copy Markdown
Member

Why

Release preparation currently requires manually updating the package version, release notes, documentation references, MkDocs navigation, and release-validation fixtures. The 1.1.2 release showed how easy it is for that process to become repetitive and partially applied.

Closes #345.

What

Adds scripts/prepare_release.py to provide one reviewable release-preparation workflow.

The helper:

  • accepts a plain MAJOR.MINOR.PATCH target version
  • updates the version-specific release files consistently
  • creates a release-notes skeleton with explicit TODO(release) markers
  • carries forward the existing Python support section
  • supports --dry-run / --check
  • refuses invalid, duplicate, older, partially prepared, or structurally inconsistent releases
  • computes all edits before writing
  • uses atomic replacement and rollback behavior for write failures
  • never commits, tags, pushes, publishes to PyPI, or creates a GitHub Release

Also adds focused unit/end-to-end tests and documents the new workflow in CONTRIBUTING.md.

Tests

The branch adds tests/test_prepare_release.py, covering:

  • version parsing and ordering
  • every release-file transformation
  • duplicate and malformed repository state
  • dry-run immutability
  • partially prepared releases
  • reruns of completed preparation
  • missing prior release notes
  • rollback after simulated write failure
  • permission and unrelated-formatting preservation
  • preparation against copies of the repository's real release files
  • prevention of shipping generated TODO(release) placeholders

The normal pull-request CI matrix should run the offline suite across supported Python versions and then build/validate the package artifacts.

After merge, the helper will also be live-tested during the next real release before any tagging or publishing step.

Risk and impact

Normal

The script edits release metadata and documentation, so mistakes could leave a release branch internally inconsistent. The implementation mitigates this by validating expected structure before changes, planning edits entirely in memory first, refusing partial states, using atomic file replacement, and rolling back completed writes if a later write fails.

Publishing, tagging, pushing, and GitHub Release creation remain manual, so the helper cannot publish an incorrect release on its own.

Add scripts/prepare_release.py, which applies the version-specific edits
each release needs (pyproject version, release-notes skeleton, release
index, mkdocs nav, README and HTTP transport version references, and the
current/historical release-notes constants in the release-validation
tests). Every edit must match its expected source text exactly once and
is computed before anything is written; invalid, older, duplicate, or
partially prepared versions are refused without changing files.
--dry-run/--check prints the diff without writing.

The notes skeleton carries TODO(release) markers, and an offline test
fails while any remain, so placeholder notes cannot ship. Closes #345.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HwZ39RgNjW1jK4tuTopfsy

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Automate release preparation and validation

2 participants