chore(release): pin pyproject to 0.7.0rc1 + fix RELEASING.md (#59)

* chore(release): pin pyproject to 0.7.0rc1 + fix RELEASING.md

The v0.7.0-rc1 release workflow failed at the version-match
validator because pyproject.toml carried "0.7.0" but the tag
normalizes to "0.7.0rc1". Bump pyproject (and the mirrored
__version__ and smoke-test assertion) to the rc form so the tag
can be re-pushed and the workflow can proceed to publish.

Fix RELEASING.md to match what the workflow actually checks:

- The pre-release checklist now says the pyproject version must
  match the tag after PEP 440 normalization, calls out that the rc
  and real-release bumps are separate commits, and lists the
  mirrored files that also need updating.
- The "Tagging the real release" section now includes the bump-to-
  final-version commit step before tagging.
- The "Iterating on an rc" section spells out the per-bump commit
  pattern and documents the recoverable tag-delete path for rcs
  that fail before reaching a publish step.

* docs(releasing): align bump examples with PR-first flow

CoPilot caught two issues in the new RELEASING.md sections:

- The "Tagging the real release" example used "chore(release):
  bump to v0.7.0" while the convention stated earlier in the doc
  is "chore(release): vX.Y.Z". Aligned the example.

- The same section's shell block conflated the local commit, PR,
  and tag steps. Since the repo doesn't allow direct push to main,
  the bump always lands via PR. Restructured to match the
  "Tagging the rc" pattern: prose lists the files to update, then
  a separate code block shows only the tag-and-push commands
  assuming main is already updated. Applied the same shape to
  "Iterating on an rc" since it had the same issue.

Author: chris-colinsky

RELEASING.md

@@ -46,11 +46,17 @@ changelog entry.
       version bump. Common spots: `README.md`, `docs/concepts/*`,
       `docs/getting-started/index.md`, `docs/reference/index.md`,
       in-code help text.
-- [ ] **`pyproject.toml` version pinned.** Set `project.version` to the
-      target version, e.g. `0.7.0`. The PEP 440 form (`0.7.0rc1` or
-      `0.7.0`) and the tag form (`v0.7.0-rc1` or `v0.7.0`) are
-      normalized to the same value, so either is accepted in the
-      `pyproject` field; the tag uses the dash form for readability.
+- [ ] **`pyproject.toml` version pinned to the tag we're about to push.**
+      The release workflow validates that the pyproject version equals
+      the tag after PEP 440 normalization. Concretely:
+      - For an rc tag like `v0.7.0-rc1`, set `project.version =
+        "0.7.0rc1"` (or `"0.7.0-rc1"`; both normalize to `0.7.0rc1`).
+      - For the real-release tag `v0.7.0`, set `project.version =
+        "0.7.0"`.
+      The rc and real-release pyproject bumps are SEPARATE COMMITS —
+      one before each tag — because the normalized forms differ.
+      Also update `src/openarmature/__init__.py`'s `__version__` and
+      `tests/test_smoke.py`'s version assertion in the same commit.
 - [ ] **Branch state.** On `main`, clean working tree, latest pulled.
       Release tags should point at commits already on `main`.
 - [ ] **CI is green on `main`.** The release workflow's `test` job
@@ -109,7 +115,16 @@ to the real-release tag with an unverified rc.
 
 ## Tagging the real release
 
-After the rc is verified, the real release is one tag away:
+After the rc is verified, prepare the real-release bump as a
+separate PR. Update:
+
+- `pyproject.toml`: `version = "0.7.0"`
+- `src/openarmature/__init__.py`: `__version__ = "0.7.0"`
+- `tests/test_smoke.py`: the version assertion
+- `CHANGELOG.md`: refresh the date if it drifted from today
+
+Commit as `chore(release): v0.7.0`, open a PR, and merge once CI is
+green. Then from a freshly-pulled `main`:
 
 ```bash
 git tag v0.7.0
@@ -136,11 +151,20 @@ After the workflow finishes:
 
 ## Iterating on an rc
 
-If the rc reveals an issue, **never move the existing rc tag**. PyPI
-and TestPyPI treat versions as immutable; bump the rc counter instead.
+If the rc reveals an issue **after it has published to TestPyPI**,
+never move the existing rc tag. PyPI and TestPyPI treat versions as
+immutable; bump the rc counter instead. Each rc bump is its own PR
+because the pyproject version has to track the new tag. Fix the
+bug, then update:
+
+- `pyproject.toml`: `version = "0.7.0rc2"`
+- `src/openarmature/__init__.py`: `__version__ = "0.7.0rc2"`
+- `tests/test_smoke.py`: the version assertion
+
+Commit as `chore(release): v0.7.0-rc2`, open a PR, and merge once
+CI is green. Then from a freshly-pulled `main`:
 
 ```bash
-# Fix the bug, commit it.
 git tag v0.7.0-rc2
 git push origin v0.7.0-rc2
 ```
@@ -149,6 +173,13 @@ Repeat verification against the new rc. Two or three rc iterations is
 fine. If the same issue keeps recurring, that's a signal to step back
 and address the design rather than spin more rc tags.
 
+If an rc tag fails the release workflow's pre-publish checks (e.g.,
+the version-match validator) so that nothing was uploaded to
+TestPyPI, the tag is recoverable: nothing is immutable on PyPI yet.
+Land the fix on `main`, delete the tag from origin (`git push origin
+:refs/tags/v0.7.0-rcN`), and re-tag the fix commit. Only do this when
+you're certain the workflow did not reach a publish step.
+
 ## Rollback
 
 PyPI does not allow re-uploading the same version. If a real release

pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "openarmature"
-version = "0.7.0"
+version = "0.7.0rc1"
 description = "Workflow framework for LLM pipelines and tool-calling agents."
 readme = "README.md"
 requires-python = ">=3.12"

src/openarmature/__init__.py

@@ -1,4 +1,4 @@
 """OpenArmature: workflow framework for LLM pipelines and tool-calling agents."""
 
-__version__ = "0.7.0"
+__version__ = "0.7.0rc1"
 __spec_version__ = "0.16.1"

tests/test_smoke.py

@@ -8,7 +8,7 @@
 
 
 def test_package_versions() -> None:
-    assert openarmature.__version__ == "0.7.0"
+    assert openarmature.__version__ == "0.7.0rc1"
     assert openarmature.__spec_version__ == "0.16.1"