Prepare 0.1.0 - #33
Open
Tippel-AI wants to merge 1 commit into
Open
Conversation
Everything the release workflow's guard checks, done in one commit so the tag can be pushed against a tree that is already consistent. Version 0.1.0.dev0 -> 0.1.0. The changelog's Unreleased section is folded into a dated 0.1.0 section rather than left beside it: none of that work ever shipped, so splitting it across two headings would imply a version nobody could install. That section is what the workflow uses verbatim as the GitHub release notes. The README flips back the three things it deliberately said while unreleased — `pipx install markproof` instead of installing from git, the status callout, and the action pinned to v0.1.0 rather than @main. The guards that kept those three honest were one-directional: they asserted the pre-release wording and skipped once the version was released, which would have gone quiet exactly when the opposite mistake becomes possible — shipping a release whose front page still tells people to install from git. They now assert both directions, and a third covers the status callout. All four mutation-tested: flipping any one of them back, or bumping the version to a .dev0 with the release wording in place, turns the suite red. They also read pyproject.toml rather than `markproof.__version__`. These tests compare two files in the working tree, and the installed metadata lags a version bump until someone reinstalls — a guard that passed or failed depending on the state of a virtualenv would be worse than none. Verified locally against the guard's own logic: tag v0.1.0 matches the version, the changelog section resolves to 230 lines of release notes, and the release is correctly classified as not a pre-release. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Everything the release workflow's guard checks, in one commit, so the tag can be
pushed against a tree that is already consistent.
What changes
pyproject.toml0.1.0.dev0→0.1.0CHANGELOG.md## [0.1.0] - 2026-09-01README.mdpipx install markproof, status callout,action@v0.1.0The changelog sections are merged rather than left side by side: none of that
work ever shipped, so two headings would imply a version nobody could install.
That section is what the workflow reads verbatim as the GitHub release notes.
The guards were one-directional, which was a trap
The three README guards from #23 asserted the pre-release wording and skipped
once the version was released. So they would have gone quiet at exactly the moment
the opposite mistake becomes possible: shipping a release whose front page still
tells people to install from git.
They now assert both directions, plus a new one for the status callout. Four
mutations, all caught:
@main0.2.0.dev0with release wording in placeThey also read
pyproject.tomlinstead ofmarkproof.__version__. These testscompare two files in the working tree, and the installed metadata lags a version
bump until someone reinstalls — a guard whose verdict depends on the state of a
virtualenv is worse than none.
Verified against the guard's own logic
Ran
release.yml's guard script locally against a hypotheticalv0.1.0:476 tests, ruff + mypy strict clean.
What is left for you, after merging this
pypi.Add yourself as a required reviewer and restrict deployment to tags
v*.GitHub → project
markproof, ownerTippel-AI, repositorymarkproof,workflow
release.yml(the filename, not the path), environmentpypi.main. Publishes nothing —both publishing jobs are gated on
github.ref_type == 'tag'.git tag -a v0.1.0 -m "markproof 0.1.0" && git push origin v0.1.0There is no API token anywhere in this. A pending publisher reserves nothing,
though — the name stays free until the first successful upload.
🤖 Generated with Claude Code