Feat #9: versionshinweis mit changelog #10

2026-08-20T23:59:25Z

florian.wilde commented

2026-08-20 23:59:25 +00:00

Bisher ließ sich der laufenden Anwendung nicht ansehen, welche Fassung sie ist. Nach einem Update war damit auch nicht zu erkennen, ob es angekommen ist — die häufigste Frage im Betrieb.

Was sich ändert

Die Fußzeile nennt die laufende Version (v1.6.0) und führt auf /version.
Dort steht der vollständige Änderungsverlauf, die laufende Fassung ist hervorgehoben.
Neu im Projekt: CHANGELOG.md.
Zu jeder Version gibt es einen annotierten Git-Tag (v1.0.0 … v1.5.0 sind gesetzt und gepusht; v1.6.0 folgt beim Merge).

Eine Quelle, zwei Ausgaben

Gepflegt wird der Verlauf in src/lib/changelog.ts. Daraus entsteht sowohl die Seite in der Anwendung als auch die CHANGELOG.md (npm run changelog); node scripts/changelog.mjs --check prüft, dass beides zusammenpasst, und ist Teil der Prüfsuite. Zwei gepflegte Listen liefen unweigerlich auseinander — und ein Changelog, der nicht stimmt, ist schlimmer als keiner.

Zu den Versionsnummern

Die Historie hatte keine Tags. Die Einträge sind deshalb nach Erscheinungstag zu Versionen zusammengefasst: die Nummern sind nachträglich vergeben, die Daten stammen aus den Commits. package.json steht jetzt auf 1.6.0.

Roadmap

Sie führt den Verlauf nicht mehr doppelt, sondern verweist auf den Changelog und behält den Blick nach vorn. Die Angleichung der geplanten Punkte an die offenen Issues passiert separat.

Geprüft

20 neue Prüfungen (Version in der Fußzeile, Seite, Sortierung, Datumsformat, Handy, dunkles Thema, Deckungsgleichheit von CHANGELOG.md und Quelle), dazu die Regression: e2e, browser, codes-view, statisch, kurzlinks, branding, darkmode, landing, auth — alles grün.

Closes #9

Bisher ließ sich der laufenden Anwendung nicht ansehen, welche Fassung sie ist. Nach einem Update war damit auch nicht zu erkennen, ob es angekommen ist — die häufigste Frage im Betrieb. **Was sich ändert** - Die Fußzeile nennt die laufende Version (`v1.6.0`) und führt auf `/version`. - Dort steht der vollständige Änderungsverlauf, die laufende Fassung ist hervorgehoben. - Neu im Projekt: `CHANGELOG.md`. - Zu jeder Version gibt es einen annotierten Git-Tag (`v1.0.0` … `v1.5.0` sind gesetzt und gepusht; `v1.6.0` folgt beim Merge). **Eine Quelle, zwei Ausgaben** Gepflegt wird der Verlauf in `src/lib/changelog.ts`. Daraus entsteht sowohl die Seite in der Anwendung als auch die `CHANGELOG.md` (`npm run changelog`); `node scripts/changelog.mjs --check` prüft, dass beides zusammenpasst, und ist Teil der Prüfsuite. Zwei gepflegte Listen liefen unweigerlich auseinander — und ein Changelog, der nicht stimmt, ist schlimmer als keiner. **Zu den Versionsnummern** Die Historie hatte keine Tags. Die Einträge sind deshalb nach **Erscheinungstag** zu Versionen zusammengefasst: die Nummern sind nachträglich vergeben, die Daten stammen aus den Commits. `package.json` steht jetzt auf `1.6.0`. **Roadmap** Sie führt den Verlauf nicht mehr doppelt, sondern verweist auf den Changelog und behält den Blick nach vorn. Die Angleichung der geplanten Punkte an die offenen Issues passiert separat. **Geprüft** 20 neue Prüfungen (Version in der Fußzeile, Seite, Sortierung, Datumsformat, Handy, dunkles Thema, Deckungsgleichheit von `CHANGELOG.md` und Quelle), dazu die Regression: e2e, browser, codes-view, statisch, kurzlinks, branding, darkmode, landing, auth — alles grün. Closes #9

florian.wilde added 1 commit 2026-08-20 23:59:25 +00:00

Versionshinweis mit Aenderungsverlauf 586e1f042f

Bisher liess sich der laufenden Anwendung nicht ansehen, welche Fassung sie
ist. Nach einem Update war damit auch nicht zu erkennen, ob es angekommen
ist — die haeufigste Frage im Betrieb.

Die Fussleiste nennt jetzt die Version und fuehrt auf /version mit dem
vollstaendigen Verlauf. Zusammengetragen ist er aus dem, was es schon gab:
dem Abschnitt „Gebaut" der Roadmap und der Git-Historie.

Gepflegt wird der Verlauf an genau einer Stelle, src/lib/changelog.ts. Daraus
entsteht sowohl die Seite als auch die CHANGELOG.md (npm run changelog); eine
Pruefung mit --check wacht darueber, dass beides zusammenpasst. Zwei gepflegte
Listen liefen unweigerlich auseinander, und ein Changelog, der nicht stimmt,
ist schlimmer als keiner.

Die Historie hatte keine Tags. Die Eintraege sind deshalb nach Erscheinungstag
zu Versionen zusammengefasst — die Nummern sind nachtraeglich vergeben, die
Daten stammen aus den Commits. Zu jeder Version gibt es jetzt einen
annotierten Tag im Repo; v1.6.0 folgt beim Merge.

Die Roadmap fuehrt den Verlauf nicht mehr doppelt, sondern verweist darauf und
behaelt den Blick nach vorn.

Refs #9

florian.wilde referenced this pull request

2026-08-20 23:59:49 +00:00

versionshinweis mit changelog #9

florian.wilde merged commit b96e9ddbe5 into main

2026-08-21 00:06:30 +00:00

florian.wilde referenced this pull request

2026-08-21 00:07:16 +00:00

versionshinweis mit changelog #9

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: florian.wilde/qrcode-generator#10