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

Closed
opened 2026-08-28 21:57:30 +02:00 by holm · 1 comment
Owner
Dimension Bewertung Einschätzung
Aufwand █░░░░░░░░░ Sehr niedrig — eine Zeile, ein Patch-Release
Nutzen ██████░░░░ Mittel — -V ist die einzige Selbstauskunft des Scripts
Bruchhäufigkeit ████████░░ Sehr hoch — bei JEDEM Release, wenn nicht von Hand vorgebumpt
Nachhaltigkeit ███░░░░░░░ Niedrig — der Sofort-Fix hält nur bis zum nächsten Release
Dringlichkeit █████░░░░░ Mittel — falsche Auskunft im Feld, bricht keine Funktion

Befund

pwgenz6c:14 trägt VERSION="0.3.0", der letzte Tag ist v0.4.0. Belegt:

$ ./pwgenz6c -V
pwgenz6c 0.3.0
$ git describe --tags --abbrev=0
v0.4.0

Ausgeliefert (Symlink ~/bin/pwgenz6c) ist damit v0.4.0 inkl. -p-pass-Pfad-Feature, das Script meldet dem Nutzer aber 0.3.0. Die Drift war seit 2026-07-12 als Wackelkante notiert und wurde bisher durch manuelles Vorbumpen vor jedem PCR abgefangen — beim v0.4.0-Release ist genau das ausgefallen.

Ursache

~/bin/release (holm.tools.public/release) ermittelt die nächste Version über git cliff --bumped-version und setzt Tag + CHANGELOG, fasst aber keine VERSION=-Variable im Script an. Es gibt also keinen Mechanismus, der Script-Version und Tag koppelt — nur Disziplin.

Umsetzung

Hier (Sofort-Fix): VERSION auf den kommenden Tag vorbumpen und v0.4.1 releasen, damit Script-Auskunft und Tag wieder deckungsgleich sind.

Ursache (Fremdrepo): Antrag an holm.tools.public/release, VERSION=-Zeilen beim Release automatisch mitzubumpen — separat dort erfasst und hier verlinkt. Solange das offen ist, bleibt das manuelle Vorbumpen vor jedem PCR Pflicht (steht im Pemmikan unter „Offene Punkte / Wackelkanten").

🤖 angelegt von Claude v00 (API/Token holm)

| Dimension | Bewertung | Einschätzung | |---|---|---| | Aufwand | `█░░░░░░░░░` | Sehr niedrig — eine Zeile, ein Patch-Release | | Nutzen | `██████░░░░` | Mittel — `-V` ist die einzige Selbstauskunft des Scripts | | Bruchhäufigkeit | `████████░░` | Sehr hoch — bei JEDEM Release, wenn nicht von Hand vorgebumpt | | Nachhaltigkeit | `███░░░░░░░` | Niedrig — der Sofort-Fix hält nur bis zum nächsten Release | | Dringlichkeit | `█████░░░░░` | Mittel — falsche Auskunft im Feld, bricht keine Funktion | ## Befund `pwgenz6c:14` trägt `VERSION="0.3.0"`, der letzte Tag ist **v0.4.0**. Belegt: ``` $ ./pwgenz6c -V pwgenz6c 0.3.0 $ git describe --tags --abbrev=0 v0.4.0 ``` Ausgeliefert (Symlink `~/bin/pwgenz6c`) ist damit v0.4.0 inkl. `-p`-pass-Pfad-Feature, das Script meldet dem Nutzer aber 0.3.0. Die Drift war seit 2026-07-12 als Wackelkante notiert und wurde bisher durch manuelles Vorbumpen vor jedem PCR abgefangen — beim v0.4.0-Release ist genau das ausgefallen. ## Ursache `~/bin/release` (holm.tools.public/release) ermittelt die nächste Version über `git cliff --bumped-version` und setzt Tag + CHANGELOG, fasst aber **keine `VERSION=`-Variable im Script an**. Es gibt also keinen Mechanismus, der Script-Version und Tag koppelt — nur Disziplin. ## Umsetzung **Hier (Sofort-Fix):** `VERSION` auf den kommenden Tag vorbumpen und v0.4.1 releasen, damit Script-Auskunft und Tag wieder deckungsgleich sind. **Ursache (Fremdrepo):** Antrag an holm.tools.public/release, `VERSION=`-Zeilen beim Release automatisch mitzubumpen — separat dort erfasst und hier verlinkt. Solange das offen ist, bleibt das manuelle Vorbumpen vor jedem PCR Pflicht (steht im Pemmikan unter „Offene Punkte / Wackelkanten"). > 🤖 angelegt von Claude v00 (API/Token holm)
Author
Owner

Erledigt mit v0.4.1. Beleg:

$ ./pwgenz6c -V
pwgenz6c 0.4.1
$ git describe --tags --abbrev=0
v0.4.1

Commit f699734 (fix(version): VERSION-Variable auf 0.4.1 gebumpt) über fix/4-version-drift nach dev gemerged, Release v0.4.1 getaggt und nach main gemerged (16cb0dd). Script-Auskunft und Tag sind wieder deckungsgleich, ~/bin/pwgenz6c zeigt als Symlink direkt auf den Checkout — der Fix ist damit sofort im Feld.

Ursache bleibt offen und liegt woanders: release#2 (VERSION= beim Release mitbumpen). Bis das umgesetzt ist, ist das manuelle Vorbumpen vor jedem PCR weiterhin Pflicht — steht so im Pemmikan unter „Offene Punkte / Wackelkanten". Dieses Issue wird trotzdem geschlossen, weil der hier belegte Defekt (falsche Selbstauskunft) behoben ist; ein Wiederauftreten wäre ein neuer Vorfall am selben strukturellen Loch.

🤖 Kommentar von Claude v00 (API/Token holm)

**Erledigt mit v0.4.1.** Beleg: ``` $ ./pwgenz6c -V pwgenz6c 0.4.1 $ git describe --tags --abbrev=0 v0.4.1 ``` Commit `f699734` (fix(version): VERSION-Variable auf 0.4.1 gebumpt) über `fix/4-version-drift` nach `dev` gemerged, Release v0.4.1 getaggt und nach `main` gemerged (`16cb0dd`). Script-Auskunft und Tag sind wieder deckungsgleich, `~/bin/pwgenz6c` zeigt als Symlink direkt auf den Checkout — der Fix ist damit sofort im Feld. **Ursache bleibt offen und liegt woanders:** [release#2](https://forgejo.mueller.network/holm.tools.public/release/issues/2) (VERSION= beim Release mitbumpen). Bis das umgesetzt ist, ist das manuelle Vorbumpen vor jedem PCR weiterhin Pflicht — steht so im Pemmikan unter „Offene Punkte / Wackelkanten". Dieses Issue wird trotzdem geschlossen, weil der hier belegte Defekt (falsche Selbstauskunft) behoben ist; ein Wiederauftreten wäre ein neuer Vorfall am selben strukturellen Loch. > 🤖 Kommentar von Claude v00 (API/Token holm)
holm closed this issue 2026-08-28 22:01:01 +02:00
Sign in to join this conversation.
No description provided.