release_type python/multi validate as config but version-file extraction is VERSION + package.json only #213

New issue

Closed

opened 2026-06-27 17:35:47 +02:00 by surveyor · 0 comments

surveyor commented

2026-06-27 17:35:47 +02:00

Owner

Surfaced by the #158 doc-drift audit (int-2).

The gap

config.sh validates release_type ∈ {node, go, python, multi} (CONFIG_VALID_RELEASE_TYPES, scripts/lib/config.sh:30), but manifest-check.sh implements version-file extraction only for VERSION (cat) and package.json (.version) basenames (scripts/manifest-check.sh:118-126). The *) branch fails with: unhandled version_file strategy: $vf (v0.1 supports VERSION + package.json).

Consequence: a python project (release_type: python, version in pyproject.toml) passes config validation, then fails at manifest-check time. The two layers are out of sync — release_type accepts more than the extraction layer implements.

Options

(a) Implement version-file extraction for pyproject.toml / __version__.py (python) and whatever multi implies — close the gap by adding the strategies.
(b) Tighten release_type validation to the actually-supported set (or gate the python/multi types behind a "supported version-file present" check) so the failure surfaces at config time with a clear message, not at manifest-check.

Either closes the validate-but-can't-extract mismatch. (a) adds capability; (b) makes the limitation honest at the earliest layer.

Note

The doc side of this is being fixed in the #158 remediation (integration.md now states version-file extraction is VERSION + package.json only, and that python/multi validate-but-need-their-version-in-a-supported-file). This tracker is the code side — the feature gap or the validation-tightening.

Audit ref: docs/drift-audit-2026-06-27.md (int-2).

Surfaced by the #158 doc-drift audit (int-2). ## The gap `config.sh` validates `release_type` ∈ `{node, go, python, multi}` (`CONFIG_VALID_RELEASE_TYPES`, `scripts/lib/config.sh:30`), but `manifest-check.sh` implements version-file extraction only for `VERSION` (cat) and `package.json` (`.version`) basenames (`scripts/manifest-check.sh:118-126`). The `*)` branch fails with: `unhandled version_file strategy: $vf (v0.1 supports VERSION + package.json)`. **Consequence:** a `python` project (`release_type: python`, version in `pyproject.toml`) passes config validation, then fails at manifest-check time. The two layers are out of sync — `release_type` accepts more than the extraction layer implements. ## Options - **(a)** Implement version-file extraction for `pyproject.toml` / `__version__.py` (python) and whatever `multi` implies — close the gap by adding the strategies. - **(b)** Tighten `release_type` validation to the actually-supported set (or gate the python/multi types behind a "supported version-file present" check) so the failure surfaces at **config time** with a clear message, not at manifest-check. Either closes the validate-but-can't-extract mismatch. (a) adds capability; (b) makes the limitation honest at the earliest layer. ## Note The **doc** side of this is being fixed in the #158 remediation (integration.md now states version-file extraction is VERSION + package.json only, and that python/multi validate-but-need-their-version-in-a-supported-file). This tracker is the **code** side — the feature gap or the validation-tightening. Audit ref: `docs/drift-audit-2026-06-27.md` (int-2).

Rows
Columns