Release-Version automatisch hochzaehlen statt fix 1.0.0 #7

New issue

Closed

opened 2026-08-27 22:36:31 +02:00 by claudecode · 1 comment

claudecode commented

2026-08-27 22:36:31 +02:00

Collaborator

Problem: Release-Tags sind immer v1.0.0-<sha> — die Versionsnummer bleibt fix auf 1.0.0, nur der Commit-SHA aendert sich.

Ziel: Tag-Schema auf auto-hochzaehlend: v<major>.<minor>.<build>

major.minor weiterhin aus package.json (Entwickler steuert Major/Minor dort).
build = git rev-list --count HEAD (monoton, zaehlt automatisch hoch).
Commit-SHA in die Release-Beschreibung, nicht in den Tag. Artefakt-Name entsprechend.

Akzeptanz:

Naechster Release z.B. v1.0.31 statt v1.0.0-<sha>; Tag eindeutig + hoeher als vorher.
Release-Beschreibung enthaelt weiter den SHA.
package.json auf 1.1.0 -> Tags v1.1.<build>.

**Problem:** Release-Tags sind immer `v1.0.0-<sha>` — die Versionsnummer bleibt fix auf `1.0.0`, nur der Commit-SHA aendert sich. **Ziel:** Tag-Schema auf auto-hochzaehlend: `v<major>.<minor>.<build>` - `major.minor` weiterhin aus `package.json` (Entwickler steuert Major/Minor dort). - `build` = `git rev-list --count HEAD` (monoton, zaehlt automatisch hoch). - Commit-SHA in die **Release-Beschreibung**, nicht in den Tag. Artefakt-Name entsprechend. **Akzeptanz:** - Naechster Release z.B. `v1.0.31` statt `v1.0.0-<sha>`; Tag eindeutig + hoeher als vorher. - Release-Beschreibung enthaelt weiter den SHA. - `package.json` auf `1.1.0` -> Tags `v1.1.<build>`.

claudecode added the

claude

in-progress

labels

2026-08-27 22:36:31 +02:00

claudecode referenced this issue from a commit

2026-08-27 22:40:50 +02:00

release: Release-Tags zaehlen automatisch hoch (#7)

claudecode commented

2026-08-27 22:43:05 +02:00

Author

Collaborator

Umgesetzt in 6d1a8b1 (release) — und direkt am eigenen Release nachgewiesen.

Der Release dieses Commits trägt den Tag v1.0.33:

Tag:          v1.0.33
Beschreibung: Automatischer Build aus Commit 6d1a8b109344787f747e82b768da3956782ba83d (6d1a8b1), Build 33
Artefakt:     aiways-backend-v1.0.33.tar.gz

Zum Vergleich der vorige: v1.0.0-e5ea822.

Umsetzung

major.minor aus package.json (unverändert bei 1.0.0, steuerst du weiter von Hand).
build = git rev-list --count HEAD.
SHA und Build-Nummer wandern in die Release-Beschreibung; der Artefakt-Name folgt dem Tag.

Ein Detail, das sonst still danebengegangen wäre: actions/checkout holt standardmäßig einen flachen Klon mit Tiefe 1 — rev-list --count hätte damit immer 1 gezählt und jeder Release hieße v1.0.1. Der Checkout im Release-Job läuft deshalb jetzt mit fetch-depth: 0.

Akzeptanzkriterien

Kriterium	Ergebnis
Nächster Release `v1.0.<build>` statt `v1.0.0-<sha>`	v1.0.33 ✅
Tag eindeutig und höher als vorher	monoton mit der Commit-Zahl ✅
Beschreibung enthält weiter den SHA	vollständiger SHA + Kurzform + Build ✅
`package.json` auf `1.1.0` → `v1.1.<build>`	vorab durchgespielt: `v1.1.31` ✅

Die Tag-Logik habe ich vor dem Push 1:1 als Shell-Schnipsel durchlaufen lassen (1.0.0→v1.0.31, 1.1.0→v1.1.31, 2.5.7→v2.5.31 — die Patch-Stelle in package.json wird also durch build ersetzt) und package.json danach unverändert gelassen. YAML des Workflows gegengeprüft, alle fünf Jobs intakt.

Dass es am Ende v1.0.33 und nicht v1.0.31 wurde, liegt schlicht an den zwei Commits, die seither dazugekommen sind — genau das soll die Build-Nummer ja tun.

**Umgesetzt** in `6d1a8b1` (release) — und direkt am eigenen Release nachgewiesen. Der Release dieses Commits trägt den Tag **`v1.0.33`**: ``` Tag: v1.0.33 Beschreibung: Automatischer Build aus Commit 6d1a8b109344787f747e82b768da3956782ba83d (6d1a8b1), Build 33 Artefakt: aiways-backend-v1.0.33.tar.gz ``` Zum Vergleich der vorige: `v1.0.0-e5ea822`. ### Umsetzung - `major.minor` aus `package.json` (unverändert bei `1.0.0`, steuerst du weiter von Hand). - `build` = `git rev-list --count HEAD`. - SHA **und** Build-Nummer wandern in die Release-Beschreibung; der Artefakt-Name folgt dem Tag. Ein Detail, das sonst still danebengegangen wäre: `actions/checkout` holt standardmäßig einen **flachen Klon mit Tiefe 1** — `rev-list --count` hätte damit immer `1` gezählt und jeder Release hieße `v1.0.1`. Der Checkout im Release-Job läuft deshalb jetzt mit `fetch-depth: 0`. ### Akzeptanzkriterien | Kriterium | Ergebnis | |---|---| | Nächster Release `v1.0.<build>` statt `v1.0.0-<sha>` | **v1.0.33** ✅ | | Tag eindeutig und höher als vorher | monoton mit der Commit-Zahl ✅ | | Beschreibung enthält weiter den SHA | vollständiger SHA + Kurzform + Build ✅ | | `package.json` auf `1.1.0` → `v1.1.<build>` | vorab durchgespielt: `v1.1.31` ✅ | Die Tag-Logik habe ich vor dem Push 1:1 als Shell-Schnipsel durchlaufen lassen (`1.0.0`→`v1.0.31`, `1.1.0`→`v1.1.31`, `2.5.7`→`v2.5.31` — die Patch-Stelle in `package.json` wird also durch `build` ersetzt) und `package.json` danach unverändert gelassen. YAML des Workflows gegengeprüft, alle fünf Jobs intakt. Dass es am Ende `v1.0.33` und nicht `v1.0.31` wurde, liegt schlicht an den zwei Commits, die seither dazugekommen sind — genau das soll die Build-Nummer ja tun.

claudecode

2026-08-27 22:43:05 +02:00