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

Closed
opened 2026-07-03 13:36:00 +02:00 by bosun · 2 comments
Owner

Finding

Config accepts release_type: node|go|python|multi. Supported basenames only VERSION + package.json. pyproject.toml + Cargo.toml explicitly rejected.

So release_type: python effectively means Python project storing version in plain VERSION file. release-please supports Node, Python (pyproject.toml), Rust/Cargo, Maven, Go, Helm, Ruby, PHP, Terraform, Dart, Elixir + monorepo path/component outputs.

Backlog rationale

Real breadth gap but not correctness issue. For v1.0.0: accurately describe current supported scope in docs + defer broadening.

Fix (post-v1.0.0)

  • Version-file strategy abstraction (release-please-style)
  • pyproject.toml strategy (TOML parse, [project] version)
  • Cargo.toml strategy
  • Maven, Helm as follow-on
  • Per-strategy test files

Anchor

External correctness cold-read (anonymous ChatGPT session, uploaded to operator 2026-07-03). Full review surfaced 10 findings across 5 blocking-v1.0.0 + 2 should-fix pre-v1.0.0 + 3 post-v1.0.0 backlog. This tracker addresses one of them.

POST-v1.0.0. v1.0.0 docs accurately scope current support.

Acceptance criteria — added and DISCHARGED 2026-09-05 (@bosun)

⚠️ This tracker had no acceptance criteria, and the work described in "Fix (post-v1.0.0)" has ALREADY SHIPPED. Criteria written from that list and graded against origin/main:

  • Version-file strategy abstractioninternal/prep/versionfiles.go (205 lines) dispatches per basename; internal/prep/tomlversion.go (131 lines) is the TOML strategy.
  • pyproject.toml strategy — accepted in supportedVersionFileBasenames, carrying the comment release-toolkit#337.
  • Cargo.toml strategy — same map, same comment.
  • Per-strategy test filesinternal/prep/versionfiles_test.go, internal/config/config_test.go. 15 subtests run, rc=0, including TestReadVersionFile_VERSION, _packageJSON, _unhandledBasename, TestBumpVersionFile_VERSION.
  • v1.0.0 obligation: docs accurately scope support. docs/integration.md:238-239 names all four basenames, :555 states which are handled today, and :571 documents that pyproject.toml and Cargo.toml are matched inside named tables.
  • Maven, Helm as follow-onRETIRED (not this tracker's scope): the body lists them as follow-on, not as part of the fix. They need their own tracker if wanted.

🔑 The guard that makes this robust rather than coincidental: TestConfigAllowlistMatchesPrepStrategies. The config allowlist and the prep dispatch are two lists in different packages that must agree — "exactly where drift goes unnoticed", per the code's own comment. A basename added to one and not the other reddens.

📌 The body's Finding is now STALE and is left in place rather than edited, since it is the record of why this was filed: "Supported basenames only VERSION + package.json. pyproject.toml + Cargo.toml explicitly rejected." That was true when filed and is false now.

⚠️ A note on how nearly this was missed: my first read of supportedVersionFileBasenames matched only the VERSION/package.json line, because that was my needle. The pyproject.toml / Cargo.toml entries are two lines below and my pattern did not reach them — so the map looked like it held two entries when it holds four. Reading the whole construct rather than the matched line is what corrected it.

## Finding Config accepts `release_type: node|go|python|multi`. Supported basenames only `VERSION` + `package.json`. pyproject.toml + Cargo.toml explicitly rejected. So `release_type: python` effectively means Python project storing version in plain VERSION file. release-please supports Node, Python (pyproject.toml), Rust/Cargo, Maven, Go, Helm, Ruby, PHP, Terraform, Dart, Elixir + monorepo path/component outputs. ## Backlog rationale Real breadth gap but not correctness issue. For v1.0.0: accurately describe current supported scope in docs + defer broadening. ## Fix (post-v1.0.0) - Version-file strategy abstraction (release-please-style) - pyproject.toml strategy (TOML parse, [project] version) - Cargo.toml strategy - Maven, Helm as follow-on - Per-strategy test files ## Anchor External correctness cold-read (anonymous ChatGPT session, uploaded to operator 2026-07-03). Full review surfaced 10 findings across 5 blocking-v1.0.0 + 2 should-fix pre-v1.0.0 + 3 post-v1.0.0 backlog. This tracker addresses one of them. POST-v1.0.0. v1.0.0 docs accurately scope current support. ## Acceptance criteria — added and DISCHARGED 2026-09-05 (@bosun) ⚠️ **This tracker had no acceptance criteria, and the work described in "Fix (post-v1.0.0)" has ALREADY SHIPPED.** Criteria written from that list and graded against `origin/main`: - [x] **Version-file strategy abstraction** — `internal/prep/versionfiles.go` (205 lines) dispatches per basename; `internal/prep/tomlversion.go` (131 lines) is the TOML strategy. - [x] **`pyproject.toml` strategy** — accepted in `supportedVersionFileBasenames`, carrying the comment `release-toolkit#337`. - [x] **`Cargo.toml` strategy** — same map, same comment. - [x] **Per-strategy test files** — `internal/prep/versionfiles_test.go`, `internal/config/config_test.go`. **15 subtests run, rc=0**, including `TestReadVersionFile_VERSION`, `_packageJSON`, `_unhandledBasename`, `TestBumpVersionFile_VERSION`. - [x] **v1.0.0 obligation: docs accurately scope support.** `docs/integration.md:238-239` names all four basenames, `:555` states which are handled today, and `:571` documents that `pyproject.toml` and `Cargo.toml` are matched inside named tables. - [x] ~~Maven, Helm as follow-on~~ — **RETIRED (not this tracker's scope):** the body lists them as follow-on, not as part of the fix. They need their own tracker if wanted. 🔑 **The guard that makes this robust rather than coincidental: `TestConfigAllowlistMatchesPrepStrategies`.** The config allowlist and the prep dispatch are two lists in different packages that must agree — *"exactly where drift goes unnoticed"*, per the code's own comment. **A basename added to one and not the other reddens.** 📌 **The body's Finding is now STALE and is left in place rather than edited**, since it is the record of why this was filed: *"Supported basenames only `VERSION` + `package.json`. pyproject.toml + Cargo.toml explicitly rejected."* **That was true when filed and is false now.** ⚠️ **A note on how nearly this was missed: my first read of `supportedVersionFileBasenames` matched only the `VERSION`/`package.json` line, because that was my needle.** The `pyproject.toml` / `Cargo.toml` entries are two lines below and my pattern did not reach them — **so the map looked like it held two entries when it holds four.** Reading the whole construct rather than the matched line is what corrected it.

docs-only ack merged via PR #351 (commit 94651ca). docs/integration.md now accurately scopes current version-file basename support (VERSION + package.json only) + links this tracker for broader-ecosystem broadening. #252 refs retired (superseded). Broader basename-strategy substrate (TOML pyproject/Cargo, Maven, Helm, other release-please-shaped ecosystems) remains this tracker's scope — targets v1.1.0.

docs-only ack merged via PR #351 (commit 94651ca). `docs/integration.md` now accurately scopes current version-file basename support (VERSION + package.json only) + links this tracker for broader-ecosystem broadening. `#252` refs retired (superseded). Broader basename-strategy substrate (TOML pyproject/Cargo, Maven, Helm, other release-please-shaped ecosystems) remains this tracker's scope — targets **v1.1.0**.
Author
Owner

Taking this off the Adoption milestone, per this tracker's own backlog rationale: "For v1.0.0: accurately describe current supported scope in docs + defer broadening."

The v1.0 half — documenting the supported set — is now #1088 and carries the milestone. #1072 landed the pyproject.toml and Cargo.toml strategies, so what remains here is Maven, Helm and the per-strategy test files: real work that does not block a stranger adopting.

Nothing is dropped; the two halves are just no longer sharing one number, so the milestone shows what actually blocks adoption.

Taking this off the Adoption milestone, per this tracker's own backlog rationale: *"For v1.0.0: accurately describe current supported scope in docs + defer broadening."* The v1.0 half — documenting the supported set — is now #1088 and carries the milestone. #1072 landed the `pyproject.toml` and `Cargo.toml` strategies, so what remains here is Maven, Helm and the per-strategy test files: real work that does not block a stranger adopting. Nothing is dropped; the two halves are just no longer sharing one number, so the milestone shows what actually blocks adoption.
bosun closed this issue 2026-09-05 02:39:10 +02:00
Sign in to join this conversation.
No project
No assignees
2 participants
Notifications
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#337
No description provided.