Skip to content

ADD VERSION-bestand fallback in release-detectie (additief)#2

Open
FreekHeijting wants to merge 1 commit into
mainfrom
feat/version-file-fallback
Open

ADD VERSION-bestand fallback in release-detectie (additief)#2
FreekHeijting wants to merge 1 commit into
mainfrom
feat/version-file-fallback

Conversation

@FreekHeijting

Copy link
Copy Markdown
Contributor

Wat

Voegt een VERSION-bestand toe als laagste manifest-precedentie in
scripts/detect-release.py, puur additief. Precedentie is nu:

  1. .claude-plugin/plugin.json
  2. pyproject.toml
  3. package.json
  4. VERSION (nieuw) — plain-text, een enkele semver-regel op de repo-root

Zo kan elke release-waardige repo een version hebben op de voor z'n type
conventionele plek, ook repos zonder taal-manifest (docs, templates, scaffolds).

Waarom

template-orchestrator en impertio-project-template hebben geen taal-manifest
op de root en werden daardoor overgeslagen door de release-detectie. Een
taal-agnostisch VERSION-bestand is de conventionele plek voor zulke repos.

Contract behouden (geen stille fallback)

  • De fail-loud-bij-geen-enkele-bron blijft intact.
  • Cruciaal: een bestaande package.json zonder version-veld faalt nog
    steeds luid en valt niet stil terug op VERSION. Elke repo houdt precies
    een version-bron. (Geverifieerd, zie test T3 hieronder.)
  • Het VERSION-bestand wordt strikt gevalideerd: precies een non-blank regel,
    die een geldige semver moet zijn. Een schemaless tekstbestand heeft geen veld
    om op te ankeren, dus de semver-vorm is de enige guard tegen een stray
    VERSION-bestand.

Lokale dry-tests (allemaal geslaagd)

Test Scenario Verwacht Resultaat
T1 VERSION-only repo manifest=VERSION, 0.1.0 OK
T2 VERSION met blanks + prerelease 1.2.3-rc.1 parse OK OK
T3 package.json zonder version + VERSION aanwezig DIE op package.json (geen fallback) OK
T4 garbage VERSION DIE (geen semver) OK
T5 multi-line VERSION DIE OK
T6 pyproject + VERSION pyproject wint OK
T7 lege VERSION DIE OK
T8 geen manifest DIE, message noemt nu VERSION OK

Release-impact

Deze repo publiceert zelf geen release: .github/workflows/release.yml is de
herbruikbare workflow (on: workflow_call), geen push-getriggerde caller. Mergen
naar main maakt de VERSION-fallback dus alleen live voor alle caller-repos; het
mint geen tag/release in deze repo.

Volgorde-afhankelijkheid: caller-repos die op een VERSION-bestand leunen
(template-orchestrator, impertio-project-template) hebben deze PR nodig op
main voordat hun release-workflow slaagt. Merge deze PR dus eerst.

NIET mergen zonder apex-review.

🤖 Generated with Claude Code

detect-release.py detecteert nu een plain-text VERSION-bestand op de repo-root
(een enkele semver-regel) als laagste precedentie NA plugin.json, pyproject.toml
en package.json. Zo kan elke release-waardige repo een version hebben op de voor
z'n type conventionele plek, ook repos zonder taal-manifest (docs, templates,
scaffolds).

De fail-loud-bij-geen-enkele-bron blijft intact: een bestaande package.json
zonder version-veld faalt nog steeds luid en valt niet stil terug op VERSION.
Het VERSION-bestand wordt strikt gevalideerd op een enkele semver-regel.

docs/release-workflow.md documenteert de VERSION-optie en de precedentie.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant