83 lines
2.9 KiB
Markdown
83 lines
2.9 KiB
Markdown
|
---
|
|||
|
|
name: bump-version
|
|||
|
|
description: >
|
|||
|
|
Versionsverwaltung für whisper-local: aktualisiert die Version in pyproject.toml nach SemVer,
|
|||
|
|
erstellt einen Git-Commit und setzt ein Git-Tag. IMMER aktivieren wenn der Nutzer einen
|
|||
|
|
Git-Commit erstellen möchte — dann zuerst fragen ob die Version mit gebumpt werden soll,
|
|||
|
|
bevor der Commit gemacht wird. Auch direkt aktivieren wenn der Nutzer die Version erhöhen,
|
|||
|
|
ein Release erstellen oder einen neuen Stand taggen möchte.
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# Version Bump für whisper-local
|
|||
|
|
|
|||
|
|
## Modus A — Commit-Anfrage (Normalfall)
|
|||
|
|
|
|||
|
|
Wenn der Nutzer einen Git-Commit erstellen möchte, **bevor** du den Commit machst:
|
|||
|
|
|
|||
|
|
Frage einmal kurz:
|
|||
|
|
> „Soll ich die Version in `pyproject.toml` mit aktualisieren? (aktuell: X.Y.Z) — patch / minor / major / nein"
|
|||
|
|
|
|||
|
|
- Antwortet er mit patch / minor / major: führe zuerst den **Versions-Bump** durch (Schritte 1–5 unten), dann committe **alle** vorgesehenen Änderungen zusammen in einem einzigen Commit (nicht zwei separate Commits).
|
|||
|
|
- Antwortet er mit nein oder macht keine Angabe: Commit wie gewohnt, kein Versions-Bump.
|
|||
|
|
|
|||
|
|
## Modus B — Direkter Versions-Bump
|
|||
|
|
|
|||
|
|
Wenn der Nutzer explizit die Version erhöhen will (z.B. „bump patch", „minor release", „Version auf 2.0.0"):
|
|||
|
|
Führe direkt Schritte 1–6 aus, ohne vorher zu fragen.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Ablauf Versions-Bump
|
|||
|
|
|
|||
|
|
### 1. Aktuelle Version ermitteln
|
|||
|
|
|
|||
|
|
Lies `pyproject.toml` und extrahiere die `version`-Zeile im `[project]`-Block.
|
|||
|
|
Format: `MAJOR.MINOR.PATCH` (z.B. `1.2.0`).
|
|||
|
|
|
|||
|
|
### 2. Neue Version berechnen
|
|||
|
|
|
|||
|
|
| Nutzerintention | Regel | Beispiel |
|
|||
|
|
|---|---|---|
|
|||
|
|
| `patch` / Bugfix / klein | PATCH +1 | `1.2.0` → `1.2.1` |
|
|||
|
|
| `minor` / Feature / neu | MINOR +1, PATCH=0 | `1.2.0` → `1.3.0` |
|
|||
|
|
| `major` / Breaking / groß | MAJOR +1, MINOR=0, PATCH=0 | `1.2.0` → `2.0.0` |
|
|||
|
|
|
|||
|
|
Wenn der Nutzer eine konkrete Zielversion nennt (z.B. „auf 2.0.0"), verwende diese direkt.
|
|||
|
|
|
|||
|
|
### 3. pyproject.toml aktualisieren
|
|||
|
|
|
|||
|
|
Ersetze exakt die Zeile `version = "ALTE_VERSION"` durch `version = "NEUE_VERSION"`.
|
|||
|
|
Ändere nichts anderes in der Datei.
|
|||
|
|
|
|||
|
|
### 4. Git-Commit erstellen
|
|||
|
|
|
|||
|
|
**Modus A:** Stage `pyproject.toml` zusammen mit allen anderen vorgesehenen Änderungen.
|
|||
|
|
Der Commit-Titel bleibt die vom Nutzer gewünschte Beschreibung — füge am Ende hinzu: `(bump NEUE_VERSION)`.
|
|||
|
|
|
|||
|
|
**Modus B:** Stage nur `pyproject.toml`, Commit-Nachricht:
|
|||
|
|
```
|
|||
|
|
chore: bump version to NEUE_VERSION
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 5. Git-Tag setzen
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
git tag -a vNEUE_VERSION -m "Version NEUE_VERSION"
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 6. Bestätigung ausgeben (nur Modus B)
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
Version: 1.2.0 → 1.3.0
|
|||
|
|
Commit: chore: bump version to 1.3.0
|
|||
|
|
Tag: v1.3.0
|
|||
|
|
|
|||
|
|
Zum Pushen: git push && git push --tags
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## Hinweise
|
|||
|
|
|
|||
|
|
- Stelle die Versions-Frage nur einmal — wenn der Nutzer nicht antwortet oder „nein" sagt, nicht erneut fragen.
|
|||
|
|
- Wenn unklar ist, welche SemVer-Komponente gemeint ist, frage einmal kurz nach.
|
|||
|
|
- Im Modus A keinen separaten Versions-Commit erstellen — alles in einen Commit.
|