From e39a5939f276b13894c9294e3630424dd9b818c0 Mon Sep 17 00:00:00 2001 From: boban Date: Tue, 23 Jun 2026 06:37:31 +0200 Subject: [PATCH] docs(changelog): condense to user-facing entries; collapse internal tooling MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The changelog mixed user-facing changes with dev-only maintainer tooling (the release pipeline, CI fixes), reading as overly detailed/unprofessional. Establish the convention up front — user-facing changes only; internal work lives in git history — and apply it: - Collapse the dev-only release-tooling versions 0.9.59–0.9.68 into a single terse 0.9.68 "Intern" entry (kept parseable so the Versions page still lists the running version). - Trim 0.9.58 to its user-facing parts (GitHub update-check, public address). - Reduce 0.9.57 to the user-facing release-channels note. Verified the Versions-page changelog parser still yields clean nodes (0.9.68 -> Intern, 0.9.58, 0.9.57, ...) with no leaked translation keys. Co-Authored-By: Claude Opus 4.8 --- CHANGELOG.md | 102 ++++++++------------------------------------------- 1 file changed, 15 insertions(+), 87 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index b8c4c67..6c028cf 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -9,109 +9,37 @@ reif, wird er nach `main` gemerged, als `vX.Y.Z` getaggt und hier unter einer eigenen Versionsüberschrift dokumentiert. Nutzer beziehen ausschließlich getaggte Releases (Kanal `stable`, optional `beta`) — niemals Entwicklungs-Builds. +**Was hier steht:** nur, was Nutzer der Installation merken — knapp, ein Eintrag +pro Änderung, gruppiert nach _Hinzugefügt / Geändert / Behoben / Sicherheit_. Rein +interne Arbeit (Wartungs-Tooling, CI, Refactorings, Tests) gehört nicht hierher, +sondern in die git-Historie. + ## [Unreleased] _Keine offenen Änderungen — der nächste Stand wird hier gesammelt und als `vX.Y.Z` getaggt._ ## [0.9.68] - 2026-06-23 -### Hinzugefügt -- **Veröffentlichen + Zurückziehen auf der Release-Seite.** Bei laufender Beta: **Deploy to Public** - (Beta in den öffentlichen Beta-Kanal) und **Promote to Stable** (als `vX.Y.Z` in den Stable-Kanal) — - beide lösen per GitHub-API (`workflow_dispatch`) die Promote-Workflows aus. Plus **Yank**: ein Public- - Release zurückziehen (löscht den Tag auf `clusev/clusev` über einen neuen `yank.yml`-Workflow), mit - Liste der letzten Public-Tags. Alle mit R5-Bestätigung + Audit; der Dashboard-Token triggert nur, der - eigentliche Public-Push/-Delete läuft im Workflow mit `PUBLIC_REPO_TOKEN`. (Token braucht `Actions: Write`.) - -## [0.9.66] - 2026-06-23 - -### Geändert -- **Pipeline-Leiste zeigt nur noch die Bau-Bereitschaft** (Tag → Mirror → CI). Der vierte - „Test-Server"-Schritt ist raus: „Staging" ist kein einzelner Server — jeder Server auf Kanal=beta - zieht eine Beta selbst, also war ein per-Server-„deployt"-Schritt willkürlich. Ob ein bestimmter - Server die Beta fährt, sieht man auf dessen Versions-Seite, nicht im Dev-Dashboard. - -## [0.9.64] - 2026-06-23 - -### Behoben -- **CI vollständig grün.** Nach dem Build-vor-Tests-Fix (0.9.63) erreichte CI erstmals den - `pint --test`-Schritt und meldete vorbestehende Style-Verstöße (routes/web.php + Tests). Per `pint` - bereinigt — Test, Style und shellcheck laufen jetzt durch. - -## [0.9.63] - 2026-06-23 - -### Behoben -- **CI war auf jedem Tag rot.** Der `php artisan test`-Schritt lief vor `npm run build`, also fehlte das - Vite-Manifest (`public/build/manifest.json`, gitignored → auf einem frischen CI-Checkout nicht da) — - jeder Voll-Seiten-Test, der ein `@vite`-Layout rendert, lief auf 500. Build jetzt vor den Tests; CI grün. - -## [0.9.62] - 2026-06-23 - -### Geändert -- **Release-Pipeline ist jetzt live.** Die Pipeline-Leiste der Dev-Release-Seite zeigt für die zuletzt - geschnittene Beta den **echten Status** pro Schritt statt einer statischen Legende: Tag (Gitea) · - Mirror (GitHub-privat, via GitHub-API) · CI (GitHub-Actions-Run-Status) · **Test-Server** (pollt ein - konfigurierbares `/version.json` → „läuft 0.9.x-betaN"). Jeder Schritt mit Status-Farbe (fertig/läuft/ - fehlgeschlagen) und Live-Poll solange CI läuft. Read-only GitHub-Token + privater Slug nur aus `.env`; - fehlt etwas oder hängt die API → ehrlich „unbekannt", nie Crash. Klärt das Modell: „Staging" = ein - beliebiger Server auf Kanal=beta (kein eigener Installer), den man als Test-Server einträgt. - -## [0.9.60] - 2026-06-23 - -### Geändert -- **Release-Seite neu gestaltet.** Die Dev-Release-Steuerung war funktional, sah aber kahl aus (Version - + vier nackte Buttons). Jetzt im „Tactical Terminal"-System: ein Versions-Hero (Version, Kanal, - Quelle), **taktile Bump-Kacheln**, die den Übergang `aktuell → Ziel` mit einem Beta-Tag-Badge zeigen - („Nächste Beta" hervorgehoben), gestylte Lauf-/Zuletzt-gepusht-Zustände und eine **Pipeline-Leiste** - (Gitea → GitHub-privat → CI → Staging). Responsiv (375/768/1280), nur Theme-Tokens, R5-Bestätigung - unverändert. - -## [0.9.59] - 2026-06-23 - -### Hinzugefügt -- **Release-Steuerung im Dashboard (Dev-only).** Eine neue „Release"-Seite (nur sichtbar wenn - `CLUSEV_RELEASE_CONTROLS=true` in der Dev-`.env`) mit einem **„Deploy to Staging"**-Button: er schneidet - eine Beta — bumpt die Version, committet, taggt `vX.Y.Z-betaN` und pusht nach Gitea (→ Mirror → CI → - Staging). Das Dashboard rechnet die Ziel-Version (Patch/Minor/Major bzw. „Nächste Beta"), die - **Host-Brücke** macht die Git-Arbeit — der Container bekommt nie den Git-Token (gleiche Isolation wie - die WireGuard-Brücke). Jede Aktion mit R5-Bestätigung + Audit-Log; Preconditions (sauberer Baum, HEAD - gepusht, kein Downgrade) und Rollback bei Push-Fehler. +### Intern +- **Release-Tooling im Dev-Dashboard + CI-Pipeline.** Beta schneiden, Live-Pipeline-Status, + Veröffentlichen / Promote-to-Stable / Yank — für Nutzer der Installation nicht sichtbar. + Details in der git-Historie. (Sammelt die internen Versionen 0.9.59–0.9.68.) ## [0.9.58] - 2026-06-22 ### Hinzugefügt -- **Update-Check unterstützt jetzt GitHub.** Bisher kannte der Versions-Check nur die Gitea-API. Damit - Public-Nutzer Updates aus dem öffentlichen GitHub-Repo sehen, spricht der Check je nach Host die - passende API: GitHub über `api.github.com` (Tags) und `raw.githubusercontent.com` (Changelog), - Gitea wie gehabt. Die Host-Logik liegt an genau einer Stelle (`ReleaseChecker`). +- **Update-Check unterstützt jetzt GitHub.** Public-Nutzer sehen Updates aus dem öffentlichen + GitHub-Repo (Tags + Changelog); Dev/Staging laufen weiter über Gitea. ### Geändert -- **Öffentliche Projekt-Adresse ist jetzt `github.com/clusev/clusev`.** README, Quelltext-/Konsolen-Branding - und die Standard-Update-Quelle zeigen aufs öffentliche Repo. Dev/Staging überschreiben das weiterhin - per `CLUSEV_REPOSITORY` in der (gitignorierten) `.env` — es steht keine private URL in versionierten Dateien. - -### Behoben -- **Interne Dev-Dokumente landen nicht im Public-Repo.** Die Release-Promotion kopiert nur lauffähigen - App-Code: `CLAUDE.md`, `rules.md`, `handoff.md` und `docs/` sind als `export-ignore` markiert und werden - von `git archive` (und damit `promote.sh`) ausgelassen — `CHANGELOG.md` bleibt bewusst öffentlich, weil - die Versions-Seite ihn vom Public-Repo abruft. -- **Update-Check-Tests sind jetzt hermetisch.** Sie setzen die Repository-URL selbst (neutraler Host) statt - sich auf die `.env` zu verlassen — so laufen sie auch in CI mit leerer `.env.example` grün. +- **Öffentliche Projekt-Adresse ist jetzt `github.com/clusev/clusev`.** README, Quelltext- und + Konsolen-Branding sowie die Standard-Update-Quelle zeigen aufs öffentliche Repo. ## [0.9.57] - 2026-06-22 ### Hinzugefügt -- **Release-Pipeline (Grundgerüst, Phase A).** Vorbereitung für die Verteilung über drei Repositories - (Gitea → GitHub-privat → GitHub-public). Alles **URL-agnostisch** — es wird **keine private - Repository-URL in versionierten Dateien** abgelegt: `config/clusev.php` setzt `repository` jetzt aus - `CLUSEV_REPOSITORY` (Default leer), und `install.sh`/`update.sh` leiten diesen Wert aus dem - Klon-Ursprung in die (gitignorierte) `.env` ab — dev zeigt so auf Gitea, Public-Nutzer aufs - Public-Repo, automatisch. -- **GitHub-Actions-Workflows.** `ci-staging` (Tests bei `v*`-Tags, optionaler Staging-Deploy bei Betas - über einen self-hosted Runner) sowie `promote-public` und `promote-stable` (`workflow_dispatch`, - abgesichert über das Environment „production"). Ein neues `scripts/promote.sh` überträgt je Release - einen **sauberen Baum** (ohne `.git`/`.github`) ins Public-Repo, sodass private CI nie öffentlich wird. -- **Kanäle:** Beta = `vX.Y.Z-betaN`, Stable = `vX.Y.Z`. Dokumentiert in der README („Release pipeline"). +- **Release-Kanäle `stable` und `beta`.** Nutzer beziehen stabile Releases (`vX.Y.Z`); wer früher + testen will, wählt den Beta-Kanal (`vX.Y.Z-betaN`) — niemals Entwicklungs-Builds. ## [0.9.56] - 2026-06-22