AndreasTharangandClaude Sonnet 5
ab416fb34c
Erster Stand des Repositories AG_QGIS/Projektwissen (bisher Arbeitstitel "Workspace", ADR 0006). Der lokale Ordner heisst weiter AG_QGIS, weil darin auch die Plugin-Klone liegen. Git verbindlich (ADR 0007), aus dem bisherigen Wiki-Konzept entwickelt: - docs/leitfaden/05_git_arbeitsweise.md mit Kanal-Kette, Branch-Namen und Gitea-Branch-Schutz. - Der Einstiegspunkt eines Fixes richtet sich nach dem Kanal, in dem der Fehler sitzt; ein Fix an testing oder stable ist erst mit der Rueckfuehrung nach unten abgeschlossen. Das fehlte bisher. - Der stabile Kanal heisst stable, nicht main: der Release-Workflow in Repository:hidden/workflows fuehrt git checkout "$CHANNEL" aus, der Branchname muss also dem Kanalnamen entsprechen. Er existiert in keinem Plugin-Repo und ist vom Maintainer anzulegen. - Der Mensch drueckt ab: .claude/settings.json sperrt push, merge, tag. - scripts/hallo.py und /hallo holen den Stand aller Klone, per Fast-Forward wo gefahrlos; nie mergen, stashen oder verwerfen. Ticketzugriff: - scripts/gitea.py liest Issues, Kommentare und PRs ueber die oeffentliche API, ohne Token, nur GET. Schreibendes nur als Entwurf in entwuerfe/. - Skill sn-ticket. Tests (ADR 0009): - docs/leitfaden/06_tests.md: Testebenen, Testpflicht, und wie eine Fachperson beurteilt, ob Tests fachlich sinnvoll sind. - scripts/testkatalog.py erzeugt docs/tests/testkatalog.md per ast-Parsing, ohne Import und ohne QGIS. Befund: nur 100 von 332 Tests haben einen Docstring, sn_basis keinen einzigen von 87. - Vorlage und erste Testkonzept-Seite mit Mermaid. Dabei gefunden und gegen origin geprueft: _ermittle_gebietstyp_aus_fbschl hat keinen Test, obwohl PR #44/#45 genau diese Funktion tolerant gemacht hat. - docs/konzept/07_qgis_tests_plan.md: Stufenplan fuer Tests gegen echtes QGIS. Dabei aufgefallen: QGIS 3.40 ist seit Januar 2026 End of Life, qgis_min steht aber noch darauf. Werkzeuge (ADR 0008): - 04_werkzeuge_einrichten.md nur noch Claude Code als CLI und in VS Code. - .vscode/ entfernt, brauchbare Einstellungen als persoenliche Vorlage. Ausserdem: README als Einstieg neu aufgebaut, Mermaid-Diagramm in schnittstellen.md repariert (unmaskierte Klammern, rendert seither nicht). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
34 lines
2.3 KiB
Markdown
34 lines
2.3 KiB
Markdown
---
|
||
name: sn-release
|
||
description: Release eines LNO-Plugins über den Gitea-Tag-Workflow (Kanäle unstable/testing/stable, Versionsschema JJ.M.N, changelog, metadata.template, Feeds in Repository). Verwenden bei "Release", "Version veröffentlichen", "Tag setzen", "testing/unstable bauen". Nur für Maintainer; Agenten bereiten vor, taggen nicht.
|
||
---
|
||
|
||
# Release erstellen
|
||
|
||
Ablauf und Fallstricke: `docs/architektur/schnittstellen.md` Abschnitt 9, `docs/wissen/fallstricke.md` (Release).
|
||
|
||
## Vorbereitung (Agent darf)
|
||
1. Kanal-Branch prüfen: `git switch unstable && git pull --ff-only` (bzw. `testing`). **Gebaut wird der Kopf dieses Branches, nicht der getaggte Commit.**
|
||
2. `changelog.txt`: Block über dem ersten `---` enthält die Einträge seit dem letzten Release; darüber Zeile `Version <JJ.M.N>-<kanal>:` ergänzen (Muster im Verlauf der Datei). Er wird zum Release-Text.
|
||
3. `.gitea/templates/metadata.template` prüfen: Name, Beschreibung, URLs zeigen auf **dieses** Repo (bekannte Fehler: Plan41 → Test_Action, FLT → `Plugin_SN_Neu`). Version wird vom Workflow gesetzt.
|
||
4. Tests: `python scripts/run_tests.py <paket> --baseline` ohne NEU ROT. Bei Fachplugins prüfen, ob die verwendete `sn_basis`-Version passende Schnittstellen hat (Änderungen seit letztem Basis-Release im Changelog).
|
||
5. Version wählen: `JJ.M.N` = Jahr.Monat.Laufnummer im Monat (z. B. `26.9.1`). Unstable und testing zählen getrennt hoch.
|
||
|
||
## Auslösen (nur Maintainer)
|
||
```bash
|
||
git tag v26.9.1-u # -u unstable, -t testing, ohne Suffix stable (derzeit ohne Branch – nicht verwenden)
|
||
git push origin v26.9.1-u
|
||
```
|
||
Der Repo-Workflow schickt einen Payload an `Repository` (Branch `hidden/workflows`); dieser baut das ZIP unter dem
|
||
Gitea-Variablennamen `ZIP_FOLDER`, erzeugt `metadata.txt` aus dem Template, legt das Gitea-Release an und aktualisiert
|
||
`plugins-<kanal>.xml`.
|
||
|
||
## Prüfen
|
||
- Gitea → Repo → Releases: Eintrag `Version 26.9.1-unstable` mit ZIP-Asset.
|
||
- `Repository/plugins-unstable.xml` enthält die neue Version.
|
||
- QGIS mit Feed `unstable`: Plugin-Aktualisierung sichtbar, Installation startet ohne Fehler.
|
||
|
||
## Nach dem Release
|
||
- `docs/status/STATUS.md`: Versionen je Kanal nachtragen.
|
||
- Bekannter offener Punkt: Release-ZIPs enthalten derzeit `AGENTS.md`, `CLAUDE.md`, `docs/`, `tests/` (Excludes im zentralen Workflow ergänzen).
|