style: lange Bindestriche durch normalen Bindestrich ersetzen
Em-Dash und En-Dash in README und docs durch normalen Bindestrich ersetzt. Reine Zeichenersetzung, keine Logikaenderung. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Claude Opus 4.8
@@ -4,17 +4,17 @@ Zentrale CI-Bausteine für IDF-Repos.
|
||||
|
||||
## Zweck
|
||||
|
||||
Dieses Repo ist die Heimat für **geteilte CI-Bausteine**, die von anderen IDF-Repos per `uses:` eingebunden werden. Vorteil: Eine Änderung an einer Stelle wirkt in allen nutzenden Repos — kein 26-facher Copy-Paste-Pflegeaufwand.
|
||||
Dieses Repo ist die Heimat für **geteilte CI-Bausteine**, die von anderen IDF-Repos per `uses:` eingebunden werden. Vorteil: Eine Änderung an einer Stelle wirkt in allen nutzenden Repos - kein 26-facher Copy-Paste-Pflegeaufwand.
|
||||
|
||||
Aktuell enthalten:
|
||||
|
||||
- `.gitea/workflows/release-plugin.yml` — Reusable Workflow für WordPress-Plugin-Releases. Bei Tag-Push (`v*.*.*`) prüft er Versions-Konsistenz über vier Sync-Stellen, extrahiert den Changelog-Block aus `CHANGELOG.md`, generiert daraus die `== Changelog ==`-Section in `readme.txt`, baut das ZIP und legt einen Gitea-Release mit ZIP-Asset an.
|
||||
- `.gitea/workflows/release-plugin.yml` - Reusable Workflow für WordPress-Plugin-Releases. Bei Tag-Push (`v*.*.*`) prüft er Versions-Konsistenz über vier Sync-Stellen, extrahiert den Changelog-Block aus `CHANGELOG.md`, generiert daraus die `== Changelog ==`-Section in `readme.txt`, baut das ZIP und legt einen Gitea-Release mit ZIP-Asset an.
|
||||
|
||||
Geplant:
|
||||
|
||||
- `lint-php.yml` — PHPCS / PHPStan für Plugin-Repos.
|
||||
- `composer/` — geteilte `composer.json`-Snippets.
|
||||
- `scripts/` — Shell-Helfer für lokales Build und Release.
|
||||
- `lint-php.yml` - PHPCS / PHPStan für Plugin-Repos.
|
||||
- `composer/` - geteilte `composer.json`-Snippets.
|
||||
- `scripts/` - Shell-Helfer für lokales Build und Release.
|
||||
|
||||
## Nutzung im Plugin-Repo
|
||||
|
||||
@@ -38,7 +38,7 @@ jobs:
|
||||
|
||||
**Auto-Modus (Standard, seit v1.2.0):** Plugin-Header-Version, PHP-Konstante, `Stable tag:` und CHANGELOG-Block hochziehen, committen, nach `main` pushen. Der Workflow erzeugt Tag `v<X.Y.Z>` selbst und legt das Release an. Wenn die Version nicht erhöht wurde, beendet der Workflow still (kein Release, keine Mail).
|
||||
|
||||
**Klassischer Modus:** Falls du lieber explizit taggst — `git tag v1.2.3 && git push --tags` triggert denselben Workflow im Tag-Modus. Beide Pfade können koexistieren.
|
||||
**Klassischer Modus:** Falls du lieber explizit taggst - `git tag v1.2.3 && git push --tags` triggert denselben Workflow im Tag-Modus. Beide Pfade können koexistieren.
|
||||
|
||||
Details und Fehlerdiagnose im [Caller-Template](docs/plugin-caller-template.md).
|
||||
|
||||
@@ -46,7 +46,7 @@ Details und Fehlerdiagnose im [Caller-Template](docs/plugin-caller-template.md).
|
||||
|
||||
Damit der Reusable Workflow durchläuft, müssen im Plugin-Repo vorhanden sein:
|
||||
|
||||
1. **`<slug>.php`** — Plugin-Haupt-PHP mit WordPress-Plugin-Header inklusive Zeile `Version: X.Y.Z`.
|
||||
1. **`<slug>.php`** - Plugin-Haupt-PHP mit WordPress-Plugin-Header inklusive Zeile `Version: X.Y.Z`.
|
||||
2. **Versions-Konstante** in einer beliebigen PHP-Datei:
|
||||
`define('IDF_<UPPER_SLUG_OHNE_IDF_>_VERSION', 'X.Y.Z');`
|
||||
Beispiel: `idf-login-branding` → `IDF_LOGIN_BRANDING_VERSION`.
|
||||
@@ -71,7 +71,7 @@ Damit der Reusable Workflow durchläuft, müssen im Plugin-Repo vorhanden sein:
|
||||
```markdown
|
||||
# Changelog
|
||||
|
||||
## v1.2.3 — 2026-04-23
|
||||
## v1.2.3 - 2026-04-23
|
||||
|
||||
### Neu
|
||||
- …
|
||||
@@ -81,7 +81,7 @@ Damit der Reusable Workflow durchläuft, müssen im Plugin-Repo vorhanden sein:
|
||||
|
||||
---
|
||||
|
||||
## v1.2.2 — 2026-04-10
|
||||
## v1.2.2 - 2026-04-10
|
||||
…
|
||||
```
|
||||
|
||||
@@ -89,9 +89,9 @@ Alle vier Versionen (Tag, Plugin-Header, PHP-Konstante, `Stable tag:`) müssen i
|
||||
|
||||
## Aufteilung Changelog-Pflege
|
||||
|
||||
- **`CHANGELOG.md`** ist die **einzige Pflege-Stelle für den Changelog** — einheitlich über alle IDF-Projekte (Software, Flow, Plugins). Du schreibst den neuen Block hier, fertig.
|
||||
- **`CHANGELOG.md`** ist die **einzige Pflege-Stelle für den Changelog** - einheitlich über alle IDF-Projekte (Software, Flow, Plugins). Du schreibst den neuen Block hier, fertig.
|
||||
- **`readme.txt`** ist WP-Standard-Metadaten: Plugin-Name, Description, `Requires PHP`, `Tested up to`, `Stable tag` usw. Pflegst du manuell, aber nur diese Felder.
|
||||
- Der Abschnitt `== Changelog ==` in `readme.txt` wird beim Release **von Actions automatisch generiert** — aus `CHANGELOG.md`. Manuelle Einträge in `readme.txt` unter `== Changelog ==` werden beim nächsten Release überschrieben.
|
||||
- Der Abschnitt `== Changelog ==` in `readme.txt` wird beim Release **von Actions automatisch generiert** - aus `CHANGELOG.md`. Manuelle Einträge in `readme.txt` unter `== Changelog ==` werden beim nächsten Release überschrieben.
|
||||
|
||||
So hat jedes Projekt im IDF genau einen Ort, an dem der Changelog lebt: `CHANGELOG.md`. WordPress-Plugins bekommen zusätzlich eine WP-native `readme.txt`, deren Changelog-Teil aber auto-befüllt wird.
|
||||
|
||||
@@ -99,9 +99,9 @@ So hat jedes Projekt im IDF genau einen Ort, an dem der Changelog lebt: `CHANGEL
|
||||
|
||||
Die Reusable Workflows selbst sind per SemVer-Tag versioniert (`v1`, `v1.2`, `v1.2.3`). Plugin-Repos referenzieren einen dieser Tags. Empfehlung:
|
||||
|
||||
- **Major-Tag (`@v1`)** — rolling, nimmt automatisch Patches und Minors mit.
|
||||
- **Minor-Tag (`@v1.2`)** — nimmt nur Patches mit.
|
||||
- **Exakt (`@v1.2.3`)** — einfriert auf genau diese Version.
|
||||
- **Major-Tag (`@v1`)** - rolling, nimmt automatisch Patches und Minors mit.
|
||||
- **Minor-Tag (`@v1.2`)** - nimmt nur Patches mit.
|
||||
- **Exakt (`@v1.2.3`)** - einfriert auf genau diese Version.
|
||||
|
||||
Breaking Changes am Workflow → neuer Major-Tag, nutzende Repos müssen manuell nachziehen.
|
||||
|
||||
@@ -110,5 +110,5 @@ Breaking Changes am Workflow → neuer Major-Tag, nutzende Repos müssen manuell
|
||||
Konzeptionelle Grundlagen und der Plugin-Release-Workflow liegen in Notion:
|
||||
|
||||
- [Deployment & Versionierung](https://www.notion.so/32b36ebfe9178147ad16ee214302c994)
|
||||
- [Plugin-Migration auf Git — Checkliste](https://www.notion.so/34b36ebfe9178195980fd4a723ebfde5)
|
||||
- [Plugin-Migration auf Git - Checkliste](https://www.notion.so/34b36ebfe9178195980fd4a723ebfde5)
|
||||
- [Git- & Issue-Workflow](https://www.notion.so/34b36ebfe91781519276f301aac0d74c)
|
||||
|
||||
Reference in New Issue
Block a user