Version-System: /api/version, Frontend, main.py-Konsistenz (inkl. ehem. #33) #32

New Issue

Lars · 2026-03-23T22:23:44+01:00

Lars commented

2026-03-23 22:23:44 +01:00

Ziel

Nachvollziehbarkeit von App-Version und Komponenten gemäß .claude/rules/ARCHITECTURE.md: öffentlicher Versions-Endpoint, Anzeige in der App, eine konsistente Quelle statt verstreuter Literals – siehe auch den früheren Teil-Task zu main.py (ehemals #33, hier integriert).

Ist-Stand (Stand develop, 2026-04)

Teil	Status
`backend/version.py` (`APP_VERSION`, `BUILD_DATE`, `MODULE_VERSIONS`, `CHANGELOG`, `DB_SCHEMA_VERSION`)	vorhanden und gepflegt
`GET /api/version` + `routers/version.py`	fehlt noch
`frontend/src/version.js` (`APP_VERSION`, `PAGE_VERSIONS`)	fehlt noch
Version-Panel auf der Settings-Seite	fehlt noch
`main.py`: Root-Health `version: "v9c-dev"` + `FastAPI(..., version="3.0.0")`	hardcoded / inkonsistent

Die ursprüngliche Issue-Beschreibung ging noch von fehlendem version.py aus; das ist überholt.

Vorgehen (Umsetzung in diesem Issue)

Backend

backend/routers/version.py: GET /api/version ohne Auth, Response aus version.py (Schema wie ARCHITECTURE / Beispiel unten; environment z. B. per Env-Variable)
Router in main.py registrieren
Konsistenz mit ehem. #33: Root-Handler / und idealerweise FastAPI(..., version=…) nutzen dieselbe öffentliche Versionsangabe wie der Endpoint (z. B. from version import APP_VERSION bzw. kleine Hilfsfunktion, keine veralteten Literals wie v9c-dev)

Frontend

frontend/src/version.js mit APP_VERSION, BUILD_DATE, PAGE_VERSIONS (Start mit relevanten Seiten, erweiterbar)
SettingsPage.jsx: Versions-Panel (Backend via /api/version, Abgleich mit gebündelter Frontend-Version, Erreichbarkeit)
api.js: z. B. getVersion() für /version

Optional / spätere Iteration (nicht Gegenstand dieses Issues)

/deploy-Slash-Command: Bump-Hinweis (wie ursprünglich erwähnt) – eigenes Mini-Issue, wenn gewünscht
Automatische Build-/Git-Identität (Commit-SHA, Tag über Gitea-Runner + Docker-Build-Args): bewusst zurückgestellt. Soll separates Issue werden, sobald die Basis aus version.py + /api/version steht; Ziel wäre weniger manuelle Konflikte bei vielen parallelen Änderungen und bessere Fehler-Zuordnung in Gitea über den Commit.

Beispiel `GET /api/version` (orientierend)

{
  "app_version": "0.9.x",
  "build_date": "2026-04-04",
  "backend_version": "0.9.x",
  "modules": { "auth": "1.2.0", "weight": "1.0.3" },
  "db_schema_version": "20260403",
  "environment": "production"
}

(app_version entspricht dem tatsächlichen Wert in version.py, nicht den alten Platzhaltern 9.3.0 aus der Erstfassung.)

Akzeptanzkriterien

GET /api/version liefert vollständige, stabile JSON-Struktur (öffentlich)
Settings zeigen System-/Modulinfos plausibel; Abweichung Frontend vs. Backend erkennbar
Keine hardcodierte Versions-Legacy mehr in main.py Root-Payload; Abgleich mit version.py / Endpoint
DB_SCHEMA_VERSION: weiter wie in version.py (manuell zum Migrationsstand; Automatik gfl. im späteren Build-/Git-Issue)

Referenz

.claude/rules/ARCHITECTURE.md Abschnitt 2 (Versionskontrollsystem)
docs/issues/REVIEW_OPEN_ISSUES_2026-04-04.md (Code-Review-Hinweise zu #32/#33)

Hinweis: Ehemaliges Issue #33 („main.py hardcoded Version“) ist in diese Beschreibung eingegangen und wird als geschlossen / Duplikat → hier geführt.

## Ziel Nachvollziehbarkeit von App-Version und Komponenten gemäß `.claude/rules/ARCHITECTURE.md`: öffentlicher Versions-Endpoint, Anzeige in der App, **eine** konsistente Quelle statt verstreuter Literals – siehe auch den früheren Teil-Task zu `main.py` (**ehemals #33**, hier integriert). --- ## Ist-Stand (Stand develop, 2026-04) | Teil | Status | |------|--------| | `backend/version.py` (`APP_VERSION`, `BUILD_DATE`, `MODULE_VERSIONS`, `CHANGELOG`, `DB_SCHEMA_VERSION`) | **vorhanden** und gepflegt | | `GET /api/version` + `routers/version.py` | **fehlt** noch | | `frontend/src/version.js` (`APP_VERSION`, `PAGE_VERSIONS`) | **fehlt** noch | | Version-Panel auf der Settings-Seite | **fehlt** noch | | `main.py`: Root-Health `version: "v9c-dev"` + `FastAPI(..., version="3.0.0")` | **hardcoded / inkonsistent** | Die ursprüngliche Issue-Beschreibung ging noch von fehlendem `version.py` aus; das ist überholt. --- ## Vorgehen (Umsetzung in diesem Issue) ### Backend - [ ] `backend/routers/version.py`: `GET /api/version` **ohne Auth**, Response aus `version.py` (Schema wie ARCHITECTURE / Beispiel unten; `environment` z. B. per Env-Variable) - [ ] Router in `main.py` registrieren - [ ] **Konsistenz mit ehem. #33:** Root-Handler `/` und idealerweise `FastAPI(..., version=…)` nutzen dieselbe **öffentliche** Versionsangabe wie der Endpoint (z. B. `from version import APP_VERSION` bzw. kleine Hilfsfunktion, **keine** veralteten Literals wie `v9c-dev`) ### Frontend - [ ] `frontend/src/version.js` mit `APP_VERSION`, `BUILD_DATE`, `PAGE_VERSIONS` (Start mit relevanten Seiten, erweiterbar) - [ ] `SettingsPage.jsx`: Versions-Panel (Backend via `/api/version`, Abgleich mit gebündelter Frontend-Version, Erreichbarkeit) - [ ] `api.js`: z. B. `getVersion()` für `/version` ### Optional / spätere Iteration (nicht Gegenstand dieses Issues) - [ ] `/deploy`-Slash-Command: Bump-Hinweis (wie ursprünglich erwähnt) – **eigenes Mini-Issue**, wenn gewünscht - [ ] **Automatische Build-/Git-Identität** (Commit-SHA, Tag über Gitea-Runner + Docker-Build-Args): bewusst **zurückgestellt**. Soll **separates Issue** werden, sobald die Basis aus `version.py` + `/api/version` steht; Ziel wäre weniger manuelle Konflikte bei vielen parallelen Änderungen und bessere Fehler-Zuordnung in Gitea über den Commit. --- ## Beispiel `GET /api/version` (orientierend) ```json { "app_version": "0.9.x", "build_date": "2026-04-04", "backend_version": "0.9.x", "modules": { "auth": "1.2.0", "weight": "1.0.3" }, "db_schema_version": "20260403", "environment": "production" } ``` (`app_version` entspricht dem tatsächlichen Wert in `version.py`, nicht den alten Platzhaltern `9.3.0` aus der Erstfassung.) --- ## Akzeptanzkriterien - [ ] `GET /api/version` liefert vollständige, stabile JSON-Struktur (öffentlich) - [ ] Settings zeigen System-/Modulinfos plausibel; Abweichung Frontend vs. Backend erkennbar - [ ] Keine hardcodierte Versions-Legacy mehr in `main.py` Root-Payload; Abgleich mit `version.py` / Endpoint - [ ] `DB_SCHEMA_VERSION`: weiter wie in `version.py` (manuell zum Migrationsstand; Automatik gfl. im späteren Build-/Git-Issue) --- ## Referenz - `.claude/rules/ARCHITECTURE.md` Abschnitt 2 (Versionskontrollsystem) - `docs/issues/REVIEW_OPEN_ISSUES_2026-04-04.md` (Code-Review-Hinweise zu #32/#33) --- **Hinweis:** Ehemaliges Issue **#33** („main.py hardcoded Version“) ist in diese Beschreibung **eingegangen** und wird als **geschlossen / Duplikat → hier** geführt.

Lars changed title from ~~Version-System implementieren (version.py + /api/version Endpoint)~~ to Version-System: /api/version, Frontend, main.py-Konsistenz (inkl. ehem. #33)

2026-04-04 15:33:37 +02:00

Lars referenced this issue

2026-04-04 15:33:52 +02:00

main.py hardcoded Version entfernen (Konsistenz) #33

Sign in to join this conversation.