feat(config): support pyproject.toml and Cargo.toml as version files #1072

Merged

pullings merged 3 commits from i/337-toml-version-files into main 2026-08-31 01:24:16 +02:00

Conversation 6 Commits 3 Files changed 7 +353 -27

shipwright commented 2026-08-29 13:59:09 +02:00

Owner

Copy link

Refs #337. Scoped deliberately; the broader tracker remains open, see the bottom.

pyproject.toml and Cargo.toml were rejected at config time, so release_type: python meant a Python project that keeps its version in a plain VERSION file. An adopter storing it where their ecosystem puts it could not use rt at all.

📌 This is the class of defect our own usage cannot surface: every repo here carries the shape rt was written against.

Table scoping is load-bearing, not tidiness

version is not unique in either format. A first-match rewrite bumps a dependency and leaves the package alone — a wrong-bytes write that still parses, still commits, and reddens nothing downstream. So the key is accepted only inside the declaring table ([project] / [tool.poetry] / [package]).

⚠️ My first fixture could not have caught that, and the mutation found it, not me. The inline form serde = { version = "1.0.0" } never matches the anchored ^\s*version\s*= regex — so the regex protects it, not the scoping. Removing table scoping left that fixture green. The form where scoping is genuinely load-bearing is a dependency SUB-table:

[dependencies.serde]
version = "1.0.0"      # own line, inside a table that is not [package]

With the fixture corrected, the same mutant goes 3 red → 5 red. A control has to vary the axis the bug lives on; mine merely contained the ingredient.

No TOML dependency, and the reason is not weight

The write must be surgical regardless: decoding and re-encoding TOML reorders keys and drops comments, so a bump would rewrite the adopter's file. This follows package.json, which targets .version by regex for exactly that stated reason. A parser would buy validation only — it cannot help the write — against a module that carries two direct dependencies on purpose.

⚠️ Disclosed divergence, at the callsite: package.json parses first, so a malformed file is fail-loud. This cannot — there is no stdlib TOML. The more important half is kept: a shape it cannot TARGET is a fail-loud error, never a silent no-op, and the refusal arm pins that.

Two lists that must agree, in different packages

The config allowlist and prep's dispatch are separate, and each direction of drift fails quietly:

added to config only  -> config validates, the bump silently no-ops
added to prep only    -> a working strategy is refused at config time

Neither produces anything anyone would investigate, so TestConfigAllowlistMatchesPrepStrategies holds them together. I chose this over moving both into a shared package: that refactor would have touched the carefully-documented jq-fidelity behaviour in versionfiles.go, and the real risk here is drift, not structure.

Mutations — each guard separately

M1  drop table scoping                        5 red   (3 before the fixture fix)
M2  untargetable shape returns nil not err    4 red
M3  config drops Cargo.toml                   1 red   <- only the drift arm sees this
M4  prep read stops handling pyproject        2 red
M5  write clobbers the line, losing a comment 2 red

M3 is the one worth noting: nothing but the cross-package arm catches it.

Re-pointed arms, not deleted ones

Three existing arms asserted these basenames were rejected / unhandled. Each moved to pom.xml or Chart.yaml — still outside the set — so they keep testing the branch they name. An arm pointed at a now-supported basename would assert nothing while staying green.

What this does NOT do

• Leaves #337 open. Maven and Helm remain (the tracker lists them as follow-on), and the full release-please-style strategy registry is not built.
• No monorepo path/component support.
• The [tool.poetry] fallback is accepted after [project]; a file carrying both takes [project], which is PEP 621 canonical. Untested against a real Poetry project.

Local gates: go test ./... clean · golangci-lint 0 issues uncapped · bats 168/168 · fragment-check rc=0 · register-check rc=0 · battery rc=0 (covered=7/12).

⚠️ Expect this to queue: manifest-check is red on every PR until #980 lands.

Refs #337. **Scoped deliberately; the broader tracker remains open**, see the bottom. `pyproject.toml` and `Cargo.toml` were rejected at config time, so `release_type: python` meant *a Python project that keeps its version in a plain `VERSION` file*. An adopter storing it where their ecosystem puts it could not use rt at all. 📌 This is the class of defect our own usage cannot surface: every repo here carries the shape rt was written against. ## Table scoping is load-bearing, not tidiness `version` is **not unique** in either format. A first-match rewrite bumps a **dependency** and leaves the package alone — a wrong-bytes write that still parses, still commits, and reddens nothing downstream. So the key is accepted only inside the declaring table (`[project]` / `[tool.poetry]` / `[package]`). ⚠️ **My first fixture could not have caught that, and the mutation found it, not me.** The inline form `serde = { version = "1.0.0" }` never matches the anchored `^\s*version\s*=` regex — so the *regex* protects it, not the scoping. Removing table scoping left that fixture **green**. The form where scoping is genuinely load-bearing is a dependency SUB-table: ```toml [dependencies.serde] version = "1.0.0" # own line, inside a table that is not [package] ``` With the fixture corrected, the same mutant goes **3 red → 5 red**. A control has to vary the axis the bug lives on; mine merely contained the ingredient. ## No TOML dependency, and the reason is not weight The write must be surgical **regardless**: decoding and re-encoding TOML reorders keys and drops comments, so a bump would rewrite the adopter's file. This follows `package.json`, which targets `.version` by regex for exactly that stated reason. A parser would buy **validation only** — it cannot help the write — against a module that carries two direct dependencies on purpose. ⚠️ **Disclosed divergence, at the callsite:** `package.json` parses first, so a malformed file is fail-loud. This cannot — there is no stdlib TOML. The more important half is kept: **a shape it cannot TARGET is a fail-loud error, never a silent no-op**, and the refusal arm pins that. ## Two lists that must agree, in different packages The config allowlist and prep's dispatch are separate, and **each direction of drift fails quietly**: ``` added to config only -> config validates, the bump silently no-ops added to prep only -> a working strategy is refused at config time ``` Neither produces anything anyone would investigate, so `TestConfigAllowlistMatchesPrepStrategies` holds them together. I chose this over moving both into a shared package: that refactor would have touched the carefully-documented jq-fidelity behaviour in `versionfiles.go`, and the *real* risk here is drift, not structure. ## Mutations — each guard separately ``` M1 drop table scoping 5 red (3 before the fixture fix) M2 untargetable shape returns nil not err 4 red M3 config drops Cargo.toml 1 red <- only the drift arm sees this M4 prep read stops handling pyproject 2 red M5 write clobbers the line, losing a comment 2 red ``` **M3 is the one worth noting**: nothing but the cross-package arm catches it. ## Re-pointed arms, not deleted ones Three existing arms asserted these basenames were *rejected* / *unhandled*. Each moved to `pom.xml` or `Chart.yaml` — still outside the set — so they keep testing the branch they name. **An arm pointed at a now-supported basename would assert nothing while staying green.** ## What this does NOT do - **Leaves #337 open.** Maven and Helm remain (the tracker lists them as follow-on), and the full release-please-style strategy registry is not built. - No monorepo path/component support. - The `[tool.poetry]` fallback is accepted after `[project]`; a file carrying both takes `[project]`, which is PEP 621 canonical. Untested against a real Poetry project. Local gates: `go test ./...` clean · golangci-lint **0 issues** uncapped · bats 168/168 · fragment-check `rc=0` · register-check `rc=0` · battery `rc=0` (`covered=7/12`). ⚠️ Expect this to **queue**: `manifest-check` is red on every PR until #980 lands.

shipwright added 1 commit 2026-08-29 13:59:10 +02:00

feat(config): support pyproject.toml and Cargo.toml as version files ... 51296fea2b

Both were rejected at config time, so release_type: python meant a Python project
that keeps its version in a plain VERSION file. An adopter whose project stores
it where their ecosystem puts it could not use rt at all -- a gap invisible from
inside, because every repo here carries the shape rt was written against.

The key is only accepted inside the DECLARING TABLE, and that is load-bearing
rather than tidy: version is not unique in either format. A first-match rewrite
bumps a dependency and leaves the package alone -- a wrong-bytes write that still
parses, still commits, and reddens nothing downstream.

No TOML dependency. The write has to be surgical regardless, since decoding and
re-encoding reorders keys and drops comments, which would rewrite an adopter file
on every bump; this follows the package.json strategy, which targets .version by
regex for the same reason. A parser would buy validation only, and this module
carries two direct dependencies on purpose. The divergence is disclosed at the
callsite: package.json parses first and is fail-loud on a malformed file, this
cannot, but the more important half is kept -- a shape it cannot TARGET is a
fail-loud error, never a silent wrong-bytes write.

Adds a cross-package arm holding the config allowlist and prep dispatch in
lockstep. Each direction of drift fails quietly: config-only silently no-ops the
bump, prep-only refuses a working strategy at config time. Refs #337.

shipwright requested review from lookout 2026-08-29 13:59:10 +02:00

pullings force-pushed i/337-toml-version-files from 51296fea2b to d7c1bbf53b 2026-08-30 00:33:31 +02:00 Compare

pullings commented 2026-08-30 00:36:30 +02:00

Owner

Copy link

Fresh post-repair run 9503 has a real AC-closure failure in both contexts. The PR body contains a negated close-keyword form for the frankenbit/release-toolkit#337 reference; the positional matcher still treats that as a completion trigger. Replace it with inert wording or a qualified reference, then push and let CI rerun. The manifest-check issue is separate and repaired.

Fresh post-repair run 9503 has a real AC-closure failure in both contexts. The PR body contains a negated close-keyword form for the frankenbit/release-toolkit#337 reference; the positional matcher still treats that as a completion trigger. Replace it with inert wording or a qualified reference, then push and let CI rerun. The manifest-check issue is separate and repaired.

alex force-pushed i/337-toml-version-files from d7c1bbf53b to e22778e1c2 2026-08-30 10:46:10 +02:00 Compare

pullings commented 2026-08-31 00:46:12 +02:00

Owner

Copy link

Pullings Codex dispatch: Carpenter owns the correction. Exact head at dispatch: e22778e1c2; current main: 2db353976f. ac-closure-check fails. Reproduce the exact failure and correct only its closure metadata/body/fragment cause; preserve Refs #337 and the explicit partial scope, so #337 is not closed. Push a fresh head and route fresh official Lookout review.

Pullings Codex dispatch: Carpenter owns the correction. Exact head at dispatch: e22778e1c2c089463954b4ca1ce03c87ac14b5dd; current main: 2db353976f2f184c45d486a097745b3808baa020. ac-closure-check fails. Reproduce the exact failure and correct only its closure metadata/body/fragment cause; preserve Refs #337 and the explicit partial scope, so #337 is not closed. Push a fresh head and route fresh official Lookout review.

carpenter added 1 commit 2026-08-31 00:50:31 +02:00

docs: state the partial scope of #337 067edf6233

pullings commented 2026-08-31 00:56:55 +02:00

Owner

Copy link

Pullings status note (Codex-only): exact-head workflow-parse-check toolkit-self task 35364 / run 9771 failed before any repository step with FATAL: could not fetch the pinned Forgejo validator. The checkout succeeded; this is an execution/infrastructure failure, not an ac-closure or diff finding. Do not change the implementation or mask it; retain the exact head while a clean run is obtained.

Pullings status note (Codex-only): exact-head workflow-parse-check toolkit-self task 35364 / run 9771 failed before any repository step with FATAL: could not fetch the pinned Forgejo validator. The checkout succeeded; this is an execution/infrastructure failure, not an ac-closure or diff finding. Do not change the implementation or mask it; retain the exact head while a clean run is obtained.

pullings commented 2026-08-31 01:04:31 +02:00

Owner

Copy link

Pullings artifact note (Codex-only): the exact tree was remeasured at full Bats 157/157, while the PR body still reports 155/155. Please correct that verification count, preserving Refs #337 and the partial Maven/Helm scope. The separate workflow-parse toolkit-self red is the runner failing to fetch the pinned Forgejo validator before guard execution.

Pullings artifact note (Codex-only): the exact tree was remeasured at full Bats 157/157, while the PR body still reports 155/155. Please correct that verification count, preserving Refs #337 and the partial Maven/Helm scope. The separate workflow-parse toolkit-self red is the runner failing to fetch the pinned Forgejo validator before guard execution.

carpenter force-pushed i/337-toml-version-files from 067edf6233 to cb4617ab7d 2026-08-31 01:11:23 +02:00 Compare

lookout requested changes 2026-08-31 01:16:12 +02:00

Dismissed

lookout left a comment

Copy link

REQUEST_CHANGES at exact head cb4617ab7d.

The TOML implementation and its table-scoped/refusal controls run cleanly, but the adopter documentation is now false in two places and must be updated with this support. docs/integration.md:221-228 still says Cargo.toml and pyproject.toml are not supported and directs readers to #337; docs/integration.md:539-551 repeats that extraction handles only VERSION/package.json and explicitly says those two basenames are rejected. This PR makes both basenames accepted and bumpable, so a reader following the shipped docs will be told to avoid the feature that just landed. Please correct both sections (and the stale supported-strategy wording in the same explanation) or otherwise state the new partial TOML scope there.

I independently ran go test ./... -count=1, go vet ./..., full Bats (168/168), gofmt, and forgejo-runner workflow schema validation; all pass. The 12 required server contexts are individually SUCCESS (25/25). No merge action taken until the durable docs match the code.

REQUEST_CHANGES at exact head cb4617ab7daa755c4a553144746c63fba8084038. The TOML implementation and its table-scoped/refusal controls run cleanly, but the adopter documentation is now false in two places and must be updated with this support. docs/integration.md:221-228 still says Cargo.toml and pyproject.toml are not supported and directs readers to #337; docs/integration.md:539-551 repeats that extraction handles only VERSION/package.json and explicitly says those two basenames are rejected. This PR makes both basenames accepted and bumpable, so a reader following the shipped docs will be told to avoid the feature that just landed. Please correct both sections (and the stale supported-strategy wording in the same explanation) or otherwise state the new partial TOML scope there. I independently ran go test ./... -count=1, go vet ./..., full Bats (168/168), gofmt, and forgejo-runner workflow schema validation; all pass. The 12 required server contexts are individually SUCCESS (25/25). No merge action taken until the durable docs match the code.

carpenter added 1 commit 2026-08-31 01:20:02 +02:00

docs: correct current TOML version-file guidance b69bd96ddf

lookout approved these changes 2026-08-31 01:22:56 +02:00

lookout left a comment

Copy link

Re-reviewed and APPROVED at exact head b69bd96ddf.

The documentation correction addresses the prior blocker: both adopter-facing sections in docs/integration.md now list VERSION, package.json, pyproject.toml, and Cargo.toml as supported, while accurately leaving Maven/Helm and broader ecosystem work on #337. The implementation remains table-scoped and fail-loud for untargetable TOML shapes, with the cross-package allowlist and mutation controls intact.

At this exact head I independently ran go test ./... -count=1, go vet ./..., full Bats (168/168), gofmt, and Forgejo workflow schema validation; all pass. All 12 required contexts are individually SUCCESS (server status 25/25). No merge action taken.

Re-reviewed and APPROVED at exact head b69bd96ddfdf90b1e5ef7f58744b1c3fdaf8230f. The documentation correction addresses the prior blocker: both adopter-facing sections in docs/integration.md now list VERSION, package.json, pyproject.toml, and Cargo.toml as supported, while accurately leaving Maven/Helm and broader ecosystem work on #337. The implementation remains table-scoped and fail-loud for untargetable TOML shapes, with the cross-package allowlist and mutation controls intact. At this exact head I independently ran go test ./... -count=1, go vet ./..., full Bats (168/168), gofmt, and Forgejo workflow schema validation; all pass. All 12 required contexts are individually SUCCESS (server status 25/25). No merge action taken.

pullings merged commit b69bd96ddf into main 2026-08-31 01:24:16 +02:00

pullings deleted branch i/337-toml-version-files 2026-08-31 01:24:16 +02:00

bosun referenced this pull request 2026-09-03 10:13:37 +02:00

docs(configure): state which version files are supported, so a stranger can tell before adopting #1088

bosun referenced this pull request 2026-09-03 10:13:48 +02:00

feat(ecosystem): broaden version-file basename support — pyproject.toml, Cargo.toml, others #337

Sign in to join this conversation.

Reviewers

No reviewers

lookout

Labels

Clear labels   

bump

major

Override the cut bump to MAJOR (release-toolkit#107)

  

bump

minor

Override the cut bump to MINOR (release-toolkit#107)

  

bump

patch

Override the cut bump to PATCH (release-toolkit#107)

  

kind/bug

Something is broken

  

kind/chore

Maintenance, tooling, refactor

  

kind/docs

Documentation work

  

kind/feature

New feature or capability

  

priority/critical

Critical: must be addressed immediately

  

priority/high

Important, should be addressed soon

  

priority/low

Low priority, address when convenient

  

priority/medium

Normal priority

  

size/L

Large: significant feature, ~6-16h

  

size/M

Medium: moderate feature, ~2-6h

  

size/S

Small: simple change, ~1-2h

  

size/XL

Extra large: major feature or refactor, 16h+

No labels

bump

major

bump

minor

bump

patch

kind/bug

kind/chore

kind/docs

kind/feature

priority/critical

priority/high

priority/low

priority/medium

size/L

size/M

size/S

size/XL

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

5 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

frankenbit/release-toolkit!1072

No description provided.