⚙️ 🤖 VERSION=-Variable im Script beim Release mitbumpen (Script meldet veraltete Version) #2

New issue

Closed

opened 2026-08-28 21:57:38 +02:00 by holm · 2 comments

holm commented

2026-08-28 21:57:38 +02:00

Owner

Dimension	Bewertung	Einschätzung
Aufwand	`██░░░░░░░░`	Niedrig — ein sed-Schritt vor dem Tag, opt-in pro Repo
Nutzen	`███████░░░`	Hoch — betrifft jedes Bash-Tool mit `VERSION=`/`-V`
Bruchhäufigkeit	`████████░░`	Sehr hoch — jedes Release ohne manuelles Vorbumpen driftet
Nachhaltigkeit	`█████████░`	Sehr hoch — einmal gelöst, Disziplin nicht mehr nötig
Dringlichkeit	`█████░░░░░`	Mittel — kein Funktionsbruch, aber falsche Selbstauskunft im Feld

Befund

release.sh ermittelt die nächste Version über git cliff --bumped-version (Zeile 31) und schreibt sie in Tag, CHANGELOG und Forgejo-Release — die im Script selbst hartkodierte VERSION=-Variable bleibt unangetastet. Die Selbstauskunft eines Tools (-V) driftet damit bei jedem Release, sofern nicht von Hand vorgebumpt wird.

Belegter Fall: holm.tools.public/pwgenz6c — Tag v0.4.0, ./pwgenz6c -V meldet 0.3.0. Die Drift war dort seit 2026-07-12 als bekannte Wackelkante mit dem Workaround „vor jedem PCR manuell vorbumpen" geführt; der Workaround ist beim v0.4.0-Release ausgefallen. Das Muster betrifft potenziell jedes Bash-Single-File-Tool der Distribution.

Vorschlag

Vor dem Tag-Schritt: in einer konfigurierbaren Datei (Default: das gleichnamige Script im Repo-Root) eine Zeile ^VERSION="..." auf $next ohne v-Präfix setzen und in den chore(release)-Commit aufnehmen. Opt-in/abschaltbar, damit Repos ohne VERSION=-Konvention unberührt bleiben; kein Treffer ⇒ stiller Skip statt Abbruch.

Auslöser: #4 (pwgenz6c VERSION-Drift). Vorschlag aus einem Fremdrepo — Umsetzung entscheidet Holm.

🤖 angelegt von Claude v00 (API/Token holm)

| Dimension | Bewertung | Einschätzung | |---|---|---| | Aufwand | `██░░░░░░░░` | Niedrig — ein sed-Schritt vor dem Tag, opt-in pro Repo | | Nutzen | `███████░░░` | Hoch — betrifft jedes Bash-Tool mit `VERSION=`/`-V` | | Bruchhäufigkeit | `████████░░` | Sehr hoch — jedes Release ohne manuelles Vorbumpen driftet | | Nachhaltigkeit | `█████████░` | Sehr hoch — einmal gelöst, Disziplin nicht mehr nötig | | Dringlichkeit | `█████░░░░░` | Mittel — kein Funktionsbruch, aber falsche Selbstauskunft im Feld | ## Befund `release.sh` ermittelt die nächste Version über `git cliff --bumped-version` (Zeile 31) und schreibt sie in Tag, CHANGELOG und Forgejo-Release — die im Script selbst hartkodierte `VERSION=`-Variable bleibt unangetastet. Die Selbstauskunft eines Tools (`-V`) driftet damit bei jedem Release, sofern nicht von Hand vorgebumpt wird. Belegter Fall: `holm.tools.public/pwgenz6c` — Tag v0.4.0, `./pwgenz6c -V` meldet `0.3.0`. Die Drift war dort seit 2026-07-12 als bekannte Wackelkante mit dem Workaround „vor jedem PCR manuell vorbumpen" geführt; der Workaround ist beim v0.4.0-Release ausgefallen. Das Muster betrifft potenziell jedes Bash-Single-File-Tool der Distribution. ## Vorschlag Vor dem Tag-Schritt: in einer konfigurierbaren Datei (Default: das gleichnamige Script im Repo-Root) eine Zeile `^VERSION="..."` auf `$next` ohne `v`-Präfix setzen und in den `chore(release)`-Commit aufnehmen. Opt-in/abschaltbar, damit Repos ohne `VERSION=`-Konvention unberührt bleiben; kein Treffer ⇒ stiller Skip statt Abbruch. Auslöser: [#4](https://forgejo.mueller.network/holm.tools.public/pwgenz6c/issues/4) (pwgenz6c VERSION-Drift). Vorschlag aus einem Fremdrepo — Umsetzung entscheidet Holm. > 🤖 angelegt von Claude v00 (API/Token holm)

holm added the

Kind/Enhancement

Priority/Medium

labels

2026-08-28 21:57:44 +02:00

holm referenced this issue from holm.tools.public/pwgenz6c

2026-08-28 22:01:00 +02:00

⚙️ 🤖 VERSION-Variable driftet gegen den Git-Tag — -V meldet 0.3.0 bei Release v0.4.0 #4

holm commented

2026-08-28 22:16:11 +02:00

Author

Owner

In Arbeit (v00, 2026-08-28) — Holm-Go auf die Umsetzung.

Geplanter Eingriff, minimal-invasiv:

Neuer Schritt zwischen Token-Prüfung und git cliff: tracked Dateien im Repo-Root (keine Rekursion) auf eine Zeile ^VERSION="…" prüfen, Treffer per sed auf die ermittelte Version ohne v-Präfix setzen, in den chore(release)-Commit aufnehmen. Kein Treffer ⇒ stiller Skip mit Hinweiszeile, kein Abbruch.
Abschaltbar über --no-version-bump; Argument-Parsing wird dafür von „nur $1 == --yes" auf eine Schleife umgestellt (unbekannte Option ⇒ Fehler statt stillem Ignorieren — Verhaltensänderung, absichtlich).
ERR-Trap: bricht das Script nach dem Bump und vor dem Commit ab, wird der Bump zurückgenommen, damit keine nicht-releasete Version im Working Tree stehen bleibt.

🤖 Kommentar von Claude v00 (API/Token holm)

**In Arbeit** (v00, 2026-08-28) — Holm-Go auf die Umsetzung. Geplanter Eingriff, minimal-invasiv: - Neuer Schritt zwischen Token-Prüfung und `git cliff`: tracked Dateien im **Repo-Root** (keine Rekursion) auf eine Zeile `^VERSION="…"` prüfen, Treffer per `sed` auf die ermittelte Version ohne `v`-Präfix setzen, in den `chore(release)`-Commit aufnehmen. Kein Treffer ⇒ stiller Skip mit Hinweiszeile, kein Abbruch. - Abschaltbar über `--no-version-bump`; Argument-Parsing wird dafür von „nur `$1 == --yes`" auf eine Schleife umgestellt (unbekannte Option ⇒ Fehler statt stillem Ignorieren — Verhaltensänderung, absichtlich). - `ERR`-Trap: bricht das Script nach dem Bump und vor dem Commit ab, wird der Bump zurückgenommen, damit keine nicht-releasete Version im Working Tree stehen bleibt. > 🤖 Kommentar von Claude v00 (API/Token holm)

holm referenced this issue from a commit

2026-08-28 22:20:31 +02:00

feat(version): VERSION=-Zeilen im Repo-Root beim Release mitbumpen

holm commented

2026-08-28 22:21:02 +02:00

Author

Owner

Umgesetzt und getestet — Commit 6d51c65, via feat/2-version-bump nach dev gemerged (9d9edb4, gepusht). Über den Symlink ~/bin/release → Checkout ist der Schritt sofort in allen Repos scharf, auch ohne Tag.

Was drin ist

Neuer Schritt 4: tracked Dateien im Repo-Root (git ls-files | grep -v '/') mit exakter Zeile ^VERSION="…"$ werden auf die ermittelte Version ohne v gesetzt und in den chore(release)-Commit aufgenommen. Kein Treffer ⇒ Hinweiszeile, kein Abbruch.
--no-version-bump schaltet den Schritt ab.
Argument-Parsing ist jetzt eine Schleife über $@. Verhaltensänderung: unbekannte Optionen brechen ab (❌ unbekannte option: …) statt still ignoriert zu werden — vorher wurde alles außer $1 == --yes verschluckt.
ERR-Trap zwischen Bump und Commit nimmt Bump-Dateien und CHANGELOG.md zurück, damit kein nie-releaseter Versionsstand liegen bleibt und der nächste Lauf nicht am Dirty-Check hängt.

Testbeleg

Wegwerf-Repo im Scratchpad mit bare-Remote, echtem git cliff/git tag -s/git push, nur der Forgejo-API-Call gestubbt:

Fall	Erwartung	Ergebnis
`tool` im Root mit `VERSION="0.1.0"`	auf `0.1.1`, im Tag enthalten	✓
`sub/nested.sh` mit `VERSION=`	unangetastet	✓
`VERSION="9.9.9"` mitten in einer Textzeile	unangetastet	✓
Repo ganz ohne `VERSION=`	Skip-Meldung, Release läuft durch	✓
`--no-version-bump`	Tag v0.1.2, Datei bleibt auf `0.1.1`	✓
`--bogus`	exit 1 mit Usage	✓
Commit scheitert nach Bump (`gpg.program` kaputt)	Rollback auf Ausgangsstand, Tree clean	✓
Wiederholungslauf direkt danach	läuft grün durch	✓

Beim Testen gefunden und gefixt: die erste Trap-Fassung nutzte git checkout -- <datei> — das schreibt aus dem Index zurück, in dem der Bump durch git add bereits lag, und stellte damit genau die Änderung wieder her, die verworfen werden sollte. Korrekt ist git checkout HEAD -- <datei>. Ohne den Integrationstest wäre der Rollback als Attrappe durchgegangen.

shellcheck und bash -n sauber. release.sh selbst trägt keine VERSION=-Zeile und läuft damit in den Skip-Pfad — Dogfooding wäre konsequent, ist aber nicht Teil dieses Issues (im Pemmikan unter „Offene Punkte" notiert).

Schließe: der beauftragte Mechanismus ist gebaut, belegt und im Feld. Der main-Merge folgt mit dem nächsten Release dieses Repos (Release-Trigger bleibt bei Holm).

🤖 Kommentar von Claude v00 (API/Token holm)

**Umgesetzt und getestet** — Commit `6d51c65`, via `feat/2-version-bump` nach `dev` gemerged (`9d9edb4`, gepusht). Über den Symlink `~/bin/release` → Checkout ist der Schritt **sofort in allen Repos scharf**, auch ohne Tag. ## Was drin ist - Neuer Schritt 4: tracked Dateien im **Repo-Root** (`git ls-files | grep -v '/'`) mit exakter Zeile `^VERSION="…"$` werden auf die ermittelte Version ohne `v` gesetzt und in den `chore(release)`-Commit aufgenommen. Kein Treffer ⇒ Hinweiszeile, kein Abbruch. - `--no-version-bump` schaltet den Schritt ab. - Argument-Parsing ist jetzt eine Schleife über `$@`. **Verhaltensänderung:** unbekannte Optionen brechen ab (`❌ unbekannte option: …`) statt still ignoriert zu werden — vorher wurde alles außer `$1 == --yes` verschluckt. - `ERR`-Trap zwischen Bump und Commit nimmt Bump-Dateien und `CHANGELOG.md` zurück, damit kein nie-releaseter Versionsstand liegen bleibt und der nächste Lauf nicht am Dirty-Check hängt. ## Testbeleg Wegwerf-Repo im Scratchpad mit bare-Remote, echtem `git cliff`/`git tag -s`/`git push`, nur der Forgejo-API-Call gestubbt: | Fall | Erwartung | Ergebnis | |---|---|---| | `tool` im Root mit `VERSION="0.1.0"` | auf `0.1.1`, im Tag enthalten | ✓ | | `sub/nested.sh` mit `VERSION=` | unangetastet | ✓ | | `VERSION="9.9.9"` mitten in einer Textzeile | unangetastet | ✓ | | Repo ganz ohne `VERSION=` | Skip-Meldung, Release läuft durch | ✓ | | `--no-version-bump` | Tag v0.1.2, Datei bleibt auf `0.1.1` | ✓ | | `--bogus` | exit 1 mit Usage | ✓ | | Commit scheitert nach Bump (`gpg.program` kaputt) | Rollback auf Ausgangsstand, Tree clean | ✓ | | Wiederholungslauf direkt danach | läuft grün durch | ✓ | **Beim Testen gefunden und gefixt:** die erste Trap-Fassung nutzte `git checkout -- <datei>` — das schreibt aus dem **Index** zurück, in dem der Bump durch `git add` bereits lag, und stellte damit genau die Änderung wieder her, die verworfen werden sollte. Korrekt ist `git checkout HEAD -- <datei>`. Ohne den Integrationstest wäre der Rollback als Attrappe durchgegangen. `shellcheck` und `bash -n` sauber. `release.sh` selbst trägt keine `VERSION=`-Zeile und läuft damit in den Skip-Pfad — Dogfooding wäre konsequent, ist aber nicht Teil dieses Issues (im Pemmikan unter „Offene Punkte" notiert). Schließe: der beauftragte Mechanismus ist gebaut, belegt und im Feld. Der `main`-Merge folgt mit dem nächsten Release dieses Repos (Release-Trigger bleibt bei Holm). > 🤖 Kommentar von Claude v00 (API/Token holm)

holm closed this issue

2026-08-28 22:21:03 +02:00