A patch release to an older version line, such as 0.1.1 after main has moved to 0.2

[FBumann]

Parked for later

Prompt: How can we release sth while main moved further? A patch to an older release...?

Then: "I think we should write this down as an issue for later."

Note

The following content was generated by AI.

Every release is cut from the current main. A fix to 0.1.x after main has moved on cannot ship as 0.1.1 today. Until a real patch release needs it, fix forward on main. This issue records what a maintenance branch would take.

Why it cannot be done today, and the change that would allow it

Why it cannot be done today (after #705 and #708):

• release.yml runs only on a push to main.
• The pypi environment accepts deployments from main only, which is the setup chore: release 0.1.0rc1 #708's checklist asks for.
• python -m tools.changelog check refuses a version that is not newer than the latest tag in the whole repository. Once v0.2.0 exists, it refuses 0.1.1.
• gh release create marks every new release as the latest. A 0.1.1 cut after 0.2.0 would show as the latest release on GitHub.

The change, as one PR when a patch release is needed:

1. The branch. A maintenance branch release/0.1.x, created from the tag v0.1.0. A fix reaches it by a PR, usually a cherry-pick from main. Its release PR puts ## 0.1.1 (date) on top of that branch's CHANGELOG.md.
2. release.yml triggers on release/** as well as main.
3. tools/changelog.py compares a new version with the tags in the branch's own history (git tag --merged HEAD), not with every tag. On release/0.1.x that is up to v0.1.0, so 0.1.1 is new. On main nothing changes.
4. gh release create gets --latest=false when the run is not on main.
5. Settings. The pypi environment's deployment branches add release/*. The branches get the same ruleset as main: required checks and no direct pushes.
6. After the release, copy the 0.1.1 section into main's CHANGELOG.md, so the history there is whole.
7. Docs. RELEASING.md gains a section "Patching an older version".

What does not need to change:

• PyPI takes 0.1.1 after 0.2.0, and pip install mathspec still resolves to the highest version.
• hatch-vcs reads the version from the tag on the maintenance branch, as it does on main.

Until then: before 1.0, fix forward. A bug found in 0.1.0 after main moved on is fixed on main and ships in the next release.