docs(caller-template): readme.txt statt CHANGELOG.md

This commit is contained in:
2026-04-24 11:57:54 +00:00
parent b64735e516
commit 4f2f9415ce
+25 -11
View File
@@ -29,26 +29,39 @@ Damit der Reusable Workflow durchläuft, müssen im Plugin-Repo vorhanden sein:
2. **Versions-Konstante** in einer PHP-Datei des Plugins: 2. **Versions-Konstante** in einer PHP-Datei des Plugins:
`define('IDF_<UPPER_SLUG_OHNE_IDF_>_VERSION', 'X.Y.Z');` `define('IDF_<UPPER_SLUG_OHNE_IDF_>_VERSION', 'X.Y.Z');`
Beispiel: Für `idf-login-branding``IDF_LOGIN_BRANDING_VERSION`. Beispiel: Für `idf-login-branding``IDF_LOGIN_BRANDING_VERSION`.
3. **`CHANGELOG.md`** im Repo-Root mit einem Block für die zu veröffentlichende Version im Format: 3. **`readme.txt`** im Repo-Root im WordPress-Standard-Format mit mindestens den folgenden Feldern und Abschnitten:
```markdown ```
## v1.2.3 — 2026-04-23 === Plugin Name ===
Contributors: ideenfabrik
Tags: …
Requires at least: 6.0
Tested up to: 6.4
Requires PHP: 7.4
Stable tag: 1.2.3
License: GPLv2 or later
### Neu == Description ==
- … Kurzbeschreibung des Plugins.
### Gefixt == Changelog ==
- …
= 1.2.3 =
* Neu: Feature xyz
* Fix: Bug abc
= 1.2.2 =
* …
``` ```
Alle drei Werte (Tag, Header, Konstante) müssen identisch sein. Pre-Flight-Check im Reusable bricht sonst ab. Alle vier Werte (Tag, Plugin-Header, PHP-Konstante, `Stable tag:` in `readme.txt`) müssen identisch sein. Der Pre-Flight-Check im Reusable bricht sonst ab.
## Release-Ablauf (Agent/Mensch) ## Release-Ablauf (Agent/Mensch)
Auf `main`, nachdem alles für die Version gemergt ist: Auf `main`, nachdem alles für die Version gemergt ist:
```bash ```bash
# 1. Plugin-Header-Version und Versions-Konstante auf X.Y.Z setzen # 1. Plugin-Header-Version, Versions-Konstante und Stable tag in readme.txt auf X.Y.Z setzen
# 2. CHANGELOG.md-Block anlegen # 2. Neuen Block in readme.txt unter == Changelog == ergänzen (neueste Version oben)
# 3. Commit # 3. Commit
git add -A git add -A
git commit -m "Release v1.2.3" git commit -m "Release v1.2.3"
@@ -78,7 +91,8 @@ Bei abgebrochenem Release:
- **„Tag entspricht nicht vMAJOR.MINOR.PATCH"** → Tag falsch formatiert. Alten Tag löschen (`git tag -d vX && git push origin :refs/tags/vX`), neu taggen. - **„Tag entspricht nicht vMAJOR.MINOR.PATCH"** → Tag falsch formatiert. Alten Tag löschen (`git tag -d vX && git push origin :refs/tags/vX`), neu taggen.
- **„Plugin-Header-Version ≠ Tag"** → `<slug>.php` Version-Zeile korrigieren, Commit, Tag neu setzen. - **„Plugin-Header-Version ≠ Tag"** → `<slug>.php` Version-Zeile korrigieren, Commit, Tag neu setzen.
- **„Konstante ≠ Tag"** → Versions-Konstante im PHP anpassen, Commit, Tag neu setzen. - **„Konstante ≠ Tag"** → Versions-Konstante im PHP anpassen, Commit, Tag neu setzen.
- **„CHANGELOG.md fehlt" / „Kein Block"** → Changelog-Eintrag für diese Version anlegen, Commit, Tag neu setzen. - **„readme.txt fehlt" / „Stable tag ≠ Tag"** → `readme.txt` im Repo-Root anlegen bzw. `Stable tag:` korrigieren, Commit, Tag neu setzen.
- **„Kein Changelog-Block für v…"** → Block `= X.Y.Z =` unter `== Changelog ==` in `readme.txt` anlegen, Commit, Tag neu setzen.
- **Release-Anlage fehlgeschlagen** → Wahrscheinlich fehlende Token-Berechtigung. `GITEA_TOKEN`-Secret prüfen oder den Standard `github.token` nutzen. - **Release-Anlage fehlgeschlagen** → Wahrscheinlich fehlende Token-Berechtigung. `GITEA_TOKEN`-Secret prüfen oder den Standard `github.token` nutzen.
Wichtig: Ein Tag, unter dem ein Release bereits existiert, kann nicht erneut einen Release erzeugen. Bei Korrekturen eine PATCH-Version höher tagen, nicht denselben Tag neu setzen. Wichtig: Ein Tag, unter dem ein Release bereits existiert, kann nicht erneut einen Release erzeugen. Bei Korrekturen eine PATCH-Version höher tagen, nicht denselben Tag neu setzen.