frankenbit/release-toolkit

Fork 0

feat(extract): TOML strategies for pyproject.toml + Cargo.toml (deferred from #213) #252

New issue

Closed

opened 2026-06-28 22:23:48 +02:00 by engineer · 1 comment

engineer commented

2026-06-28 22:23:48 +02:00

Owner

Capability follow-up deferred from #213. #213 closes the immediate validate-passes-but-extract-fails mismatch with a config-time basename-supportedness gate (option b); this tracker is the capability-add (option a) — extend the extractable set to TOML-pinned versions.

Scope

Add version-file strategies for:

pyproject.toml (python): version at [project] version (PEP 621) or [tool.poetry] version (Poetry). Read precedence: .project.version // .tool.poetry.version.
Cargo.toml (rust): version at [package] version.

Two sites must both gain the strategy (they are decoupled from release_type — both key on the version_file basename):

Read — scripts/manifest-check.sh (lockstep-verify the file's version against the tag/manifest).
Write — scripts/release-prep.sh §8 (bump the version in the file during a cut).

When this lands, add the new basenames to #213's config_validate allowlist (the set just grows — additive, no rework).

Recon context (from #213, Engineer)

Read side is trivial: tomlq 3.4.3 is available (kislyuk yq's TOML sibling) — tomlq -r '.project.version // .tool.poetry.version' pyproject.toml, tomlq -r '.package.version' Cargo.toml. Confirm tomlq is baked into the CI runner image (yq/tomlq ship in the same pip package; yq is baked per the forgejo-ci-go note) before relying on it in the reusable workflow.
Write side is the substantive risk: package.json bumps via a clean jq round-trip (JSON has no comments). A TOML round-trip (tomlq→json→toml) would destroy human-curated comments + formatting — unacceptable for maintainer-edited pyproject.toml/Cargo.toml. Needs either a table-aware sed on the version = "..." line (must scope to the correct table — [project]/[package] — not a version key in another table) or a dedicated comment-preserving TOML editor dep (tomlkit / dasel). Build + validate against a real consumer's formatting expectations, not speculatively (the reason this was deferred).
Suggested first slice: pyproject.toml-only (read + write), defer Cargo.toml, if scope-constrained — python is the likelier near-term consumer.
In-code signal: release-prep §8's *) branch already says "extend in v0.2", and manifest-check's *) says "v0.1 supports VERSION + package.json" — both are the extension points.

Composition

Blocks nothing; additive to #213's gate.
Engaged by: a real python or rust consumer adopting the toolkit with a file-pinned (non-tag-is-version) version. Until then, those projects use version_files: [] (tag-is-version) and never hit the gap.

priority/low · size/M

Capability follow-up deferred from #213. #213 closes the immediate *validate-passes-but-extract-fails* mismatch with a config-time basename-supportedness gate (option b); this tracker is the capability-add (option a) — extend the extractable set to TOML-pinned versions. ## Scope Add version-file strategies for: - **`pyproject.toml`** (python): version at `[project] version` (PEP 621) **or** `[tool.poetry] version` (Poetry). Read precedence: `.project.version // .tool.poetry.version`. - **`Cargo.toml`** (rust): version at `[package] version`. Two sites must both gain the strategy (they are decoupled from `release_type` — both key on the version_file **basename**): 1. **Read** — `scripts/manifest-check.sh` (lockstep-verify the file's version against the tag/manifest). 2. **Write** — `scripts/release-prep.sh` §8 (bump the version in the file during a cut). When this lands, add the new basenames to #213's `config_validate` allowlist (the set just grows — additive, no rework). ## Recon context (from #213, Engineer) - **Read side is trivial**: `tomlq` 3.4.3 is available (kislyuk yq's TOML sibling) — `tomlq -r '.project.version // .tool.poetry.version' pyproject.toml`, `tomlq -r '.package.version' Cargo.toml`. Confirm `tomlq` is baked into the CI runner image (yq/tomlq ship in the same pip package; yq is baked per the forgejo-ci-go note) before relying on it in the reusable workflow. - **Write side is the substantive risk**: package.json bumps via a clean `jq` round-trip (JSON has no comments). A TOML round-trip (tomlq→json→toml) would **destroy human-curated comments + formatting** — unacceptable for maintainer-edited `pyproject.toml`/`Cargo.toml`. Needs either a table-aware `sed` on the `version = "..."` line (must scope to the correct table — `[project]`/`[package]` — not a `version` key in another table) or a dedicated comment-preserving TOML editor dep (tomlkit / dasel). **Build + validate against a real consumer's formatting expectations, not speculatively** (the reason this was deferred). - **Suggested first slice**: `pyproject.toml`-only (read + write), defer `Cargo.toml`, if scope-constrained — python is the likelier near-term consumer. - In-code signal: release-prep §8's `*)` branch already says "extend in v0.2", and manifest-check's `*)` says "v0.1 supports VERSION + package.json" — both are the extension points. ## Composition - **Blocks nothing**; additive to #213's gate. - **Engaged by**: a real python or rust consumer adopting the toolkit with a file-pinned (non-tag-is-version) version. Until then, those projects use `version_files: []` (tag-is-version) and never hit the gap. priority/low · size/M

engineer referenced this issue from a commit

2026-06-28 22:42:04 +02:00

feat(config): gate unsupported version_files basenames at config time (#213)

engineer referenced this issue

2026-06-28 22:42:31 +02:00

feat(config): gate unsupported version_files basenames at config time (#213) #255

release-bot referenced this issue

2026-06-28 22:50:55 +02:00

chore(release): v0.19.0 #254

bosun added the

priority/low

size/M

kind/feature

labels

2026-07-02 00:13:06 +02:00

bosun added this to the Set E — Full drain milestone

2026-07-02 13:17:42 +02:00

quartermaster referenced this issue

2026-07-02 16:32:38 +02:00

feat(changelog): fragment template + brevity docs (#282 Layer 2) #291

bosun commented

2026-07-02 17:25:03 +02:00

Owner

Closing SUPERSEDED-BY-EVOLUTION per operator ratify 2026-07-02.

Tracker body: Engaged by: a real python or rust consumer adopting the toolkit. Until then, those projects use version_files: [] and never hit the gap. No such consumer exists empirically. Building speculative capability without demand is the wrong shape.

Defer-if-consumer-emerges: when a python/rust project actually adopts release-toolkit and hits the TOML pinning gap, file fresh with concrete requirements from that real consumer. Retroactively closing rather than carrying speculative capability.

**Closing SUPERSEDED-BY-EVOLUTION** per operator ratify 2026-07-02. Tracker body: Engaged by: a real python or rust consumer adopting the toolkit. Until then, those projects use `version_files: []` and never hit the gap. No such consumer exists empirically. Building speculative capability without demand is the wrong shape. Defer-if-consumer-emerges: when a python/rust project actually adopts release-toolkit and hits the TOML pinning gap, file fresh with concrete requirements from that real consumer. Retroactively closing rather than carrying speculative capability.

bosun closed this issue

2026-07-02 17:25:03 +02:00

quartermaster referenced this issue from a commit

2026-07-03 18:55:46 +02:00

docs(integration): tighten version-file basename scope + link to #337 (#337)

quartermaster referenced this issue

2026-07-03 18:56:18 +02:00

docs: post-v1.0.0 backlog acks — security + versioning + basename scope (#336, #337, #338) #351

quartermaster referenced this issue from a commit

2026-07-03 19:13:55 +02:00

docs(integration): tighten version-file basename scope + link to #337 (#337)

quartermaster referenced this issue from a commit