Agent-almanac plan-release-cycle

install

source · Clone the upstream repo

git clone https://github.com/pjt222/agent-almanac

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/pjt222/agent-almanac "$T" && mkdir -p ~/.claude/skills && cp -r "$T/i18n/de/skills/plan-release-cycle" ~/.claude/skills/pjt222-agent-almanac-plan-release-cycle-2b2913 && rm -rf "$T"

manifest: i18n/de/skills/plan-release-cycle/SKILL.md

source content

Release-Zyklus planen

Einen strukturierten Software-Release-Zyklus planen durch Definition der Strategie (kalenderbasiert oder funktionsbasiert), Festlegung von Meilensteinen mit Zieldaten, Etablierung von Feature-Freeze-Kriterien, Verwaltung von Release Candidates, Definition von Go/No-Go-Checklisten und Dokumentation von Rollback-Plaenen. Erzeugt ein

RELEASE-PLAN.md

-Artefakt, das das Team von der Entwicklung bis zum Release leitet.

Wann verwenden

Beginn der Planung fuer ein Major- oder Minor-Versions-Release
Uebergang von Ad-hoc-Releases zu einer strukturierten Release-Kadenz
Koordination eines Releases ueber mehrere Teams oder Komponenten
Definition von Qualitaets-Gates und Release-Kriterien fuer ein reguliertes Projekt
Planung des ersten oeffentlichen Releases (v1.0.0) eines Projekts

Eingaben

Erforderlich: Ziel-Versionsnummer (z.B. v2.0.0)
Erforderlich: Gewuenschtes Release-Datum oder Release-Fenster
Erforderlich: Liste geplanter Funktionen oder Umfang (Backlog, Roadmap oder Beschreibung)
Optional: Teamgroesse und Verfuegbarkeit
Optional: Release-Strategie-Praeferenz (kalenderbasiert oder funktionsbasiert)
Optional: Regulatorische oder Compliance-Anforderungen, die das Release beeinflussen
Optional: Fruehere Release-Geschwindigkeit oder Zyklusdauerdaten

Vorgehensweise

Schritt 1: Release-Strategie bestimmen

Zwischen zwei primaeren Strategien waehlen:

Kalenderbasiert (zeitlich begrenzt):

Release nach festem Zeitplan (z.B. alle 4 Wochen, quartalsweise)
Funktionen, die nicht bereit sind, werden auf das naechste Release verschoben
Vorhersagbar fuer Benutzer und nachgelagerte Projekte
Am besten fuer: Bibliotheken, Frameworks, Werkzeuge mit externen Nutzern

Funktionsbasiert (umfangsgesteuert):

Release, wenn ein definierter Satz von Funktionen vollstaendig ist
Datum passt sich dem Umfang an
Risiko von Umfangserweiterung und unbefristeten Verzoegerungen
Am besten fuer: interne Werkzeuge, Erst-Releases, grosse Neuentwicklungen

Fuer die meisten Projekte funktioniert ein hybrider Ansatz gut: ein Zieldatum mit definiertem Umfang setzen, aber einen 1-2-Wochen-Puffer zulassen. Wenn der Umfang bis zur Puffer-Frist nicht erreicht ist, verbleibende Funktionen verschieben.

Die Strategiewahl mit Begruendung dokumentieren.

Erwartet: Release-Strategie mit Begruendung dokumentiert, passend zum Projektkontext.

Bei Fehler: Wenn sich das Team nicht auf eine Strategie einigen kann, standardmaessig kalenderbasiert mit einer Funktionsprioritaetsliste waehlen. Zeitliche Begrenzung erzwingt Priorisierungsentscheidungen.

Schritt 2: Meilensteine definieren

Den Release-Zyklus in Phasen mit Zieldaten unterteilen:

## Release Plan: v2.0.0

### Timeline

| Phase | Start | End | Duration | Description |
|---|---|---|---|---|
| Development | 2026-02-17 | 2026-03-14 | 4 weeks | Active feature development |
| Feature Freeze | 2026-03-15 | 2026-03-15 | 1 day | No new features merged after this date |
| Stabilization | 2026-03-15 | 2026-03-21 | 1 week | Bug fixes, documentation, testing only |
| RC1 | 2026-03-22 | 2026-03-22 | 1 day | First release candidate tagged |
| RC Testing | 2026-03-22 | 2026-03-28 | 1 week | Community/team testing of RC |
| RC2 (if needed) | 2026-03-29 | 2026-03-29 | 1 day | Second RC if critical issues found |
| Go/No-Go | 2026-03-31 | 2026-03-31 | 1 day | Final decision meeting |
| Release | 2026-04-01 | 2026-04-01 | 1 day | Tag, publish, announce |

Typische Phasendauern:

Entwicklung: 50-70% des Gesamtzyklus
Stabilisierung: 15-25% des Gesamtzyklus
RC-Tests: 10-20% des Gesamtzyklus

Erwartet: Meilensteintabelle mit Daten, Dauern und Beschreibungen fuer jede Phase.

Bei Fehler: Wenn der Zeitplan zu komprimiert ist (Stabilisierung < 1 Woche), entweder das Release-Datum verlaengern oder den Umfang reduzieren. Niemals die Stabilisierung ueberspringen.

Schritt 3: Feature-Freeze-Kriterien festlegen

Definieren, was "Feature Freeze" fuer dieses Release bedeutet:

### Feature Freeze Criteria

After feature freeze (2026-03-15):
- **Allowed**: Bug fixes, test additions, documentation updates, dependency security patches
- **Not allowed**: New features, API changes, refactoring, dependency upgrades (non-security)
- **Exception process**: Feature freeze exceptions require written justification and approval from [release owner]

### Feature Priority List
| Priority | Feature | Status | Owner | Notes |
|---|---|---|---|---|
| P0 (must) | New export format | In progress | [Name] | Blocks release |
| P0 (must) | Security audit fixes | Not started | [Name] | Compliance requirement |
| P1 (should) | Performance optimization | In progress | [Name] | Defer if not ready |
| P2 (nice) | Dark mode support | Not started | [Name] | Defer to v2.1.0 if needed |

P0-Funktionen blockieren das Release. P1-Funktionen sollten eingeschlossen werden, wenn sie bereit sind. P2-Funktionen werden ohne Verzoegerung verschoben.

Erwartet: Feature-Freeze-Regeln mit Ausnahmeverfahren und priorisierter Funktionsliste dokumentiert.

Bei Fehler: Wenn P0-Funktionen Gefahr laufen, den Freeze-Termin zu verpassen, sofort eskalieren. Optionen: Entwicklungsphase verlaengern, die Funktion in eine kleinere Liefereinheit aufteilen oder auf ein Punkt-Release (v2.0.1) verschieben.

Schritt 4: Release-Candidate-Prozess planen

Definieren, wie Release Candidates erzeugt und getestet werden:

### Release Candidate Process

1. **RC1 Tag**: Tag from the stabilization branch after all P0 features merged and CI green
   ```bash
   git tag -a v2.0.0-rc.1 -m "Release candidate 1 for v2.0.0"

RC Distribution: Publish RC to staging/testing channel
- R:
```
install.packages("pkg", repos = "https://staging.r-universe.dev/user")
```
- Node.js:
```
npm install pkg@next
```
- Internal: Deploy to staging environment
RC Testing Period: 5-7 business days
- Run full test suite including integration tests
- Verify all P0 features work as documented
- Test upgrade path from previous version
- Check for regressions in existing functionality
RC Evaluation:
- No critical/high bugs: Proceed to release
- Critical bugs found: Fix, tag RC2, restart testing period
- More than 2 RCs needed: Revisit scope and timeline

RC2+ Tags: Only if critical issues found in previous RC

git tag -a v2.0.0-rc.2 -m "Release candidate 2 for v2.0.0"


**Erwartet:** RC-Prozess dokumentiert mit Tagging-Konvention, Verteilungsmethode, Test-Checkliste und Eskalationskriterien.

**Bei Fehler:** Wenn der RC-Prozess uebersprungen wird (Druck zum Release), das Risiko dokumentieren. Ungetestete Releases haben eine hoehere Rollback-Wahrscheinlichkeit.

### Schritt 5: Go/No-Go-Checkliste definieren

Die Kriterien erstellen, die vor der Release-Freigabe erfuellt sein muessen:

```markdown
### Go/No-Go Checklist

#### Must Pass (release blocked if any fail)
- [ ] All CI checks passing on release branch
- [ ] Zero critical bugs open against this version
- [ ] Zero high-severity security vulnerabilities
- [ ] All P0 features verified and documented
- [ ] Changelog complete and reviewed
- [ ] Upgrade path tested from previous version (v1.x -> v2.0.0)
- [ ] License and attribution files up to date

#### Should Pass (release proceeds with documented risk)
- [ ] Zero high bugs open (non-critical)
- [ ] All P1 features included
- [ ] Performance benchmarks within acceptable range
- [ ] Documentation reviewed and spell-checked
- [ ] External dependencies at latest stable versions

#### Decision
- **Go**: All "Must Pass" items checked, majority of "Should Pass" items checked
- **No-Go**: Any "Must Pass" item unchecked
- **Conditional Go**: All "Must Pass" checked, significant "Should Pass" items unchecked — document accepted risks

Erwartet: Go/No-Go-Checkliste mit klaren Bestanden/Nicht-Bestanden-Kriterien und Entscheidungsregeln.

Bei Fehler: Wenn das Go/No-Go-Meeting zu einem No-Go fuehrt, die blockierenden Punkte identifizieren, Verantwortliche zuweisen, ein neues Zieldatum setzen (typischerweise 1-2 Wochen spaeter) und den Release-Plan aktualisieren.

Schritt 6: Rollback-Plan dokumentieren

Definieren, wie zurueckgerollt wird, wenn das Release kritische Probleme in der Produktion verursacht:

### Rollback Plan

#### Rollback Triggers
- Critical bug affecting >10% of users
- Data corruption or loss
- Security vulnerability introduced by the release
- Breaking change not documented in changelog

#### Rollback Procedure
1. **Revert package registry**: Unpublish or yank the release
   - R/CRAN: Contact CRAN maintainers (cannot self-unpublish)
   - npm: `npm unpublish pkg@2.0.0` (within 72 hours)
   - GitHub: Mark release as pre-release, publish point fix

2. **Communicate**: Notify users via GitHub issue, mailing list, or social channels
   - Template: "v2.0.0 has been rolled back due to [issue]. Please use v1.x.y until a fix is released."

3. **Fix forward**: Prefer a v2.0.1 patch release over a full rollback when possible

4. **Post-mortem**: Conduct a post-mortem within 48 hours of rollback to identify process gaps

#### Point Release Policy
- v2.0.1 for critical bug fixes within 1 week of release
- v2.0.2 for additional fixes within 2 weeks
- Patch releases do not require full RC cycle but must pass CI and critical test suite

Den vollstaendigen Release-Plan in

RELEASE-PLAN.md

oder

RELEASE-PLAN-v2.0.0.md

schreiben.

Erwartet: Rollback-Plan dokumentiert mit Ausloesern, Verfahren, Kommunikationsvorlage und Punkt-Release-Richtlinie. Vollstaendige RELEASE-PLAN.md geschrieben.

Bei Fehler: Wenn Rollback nicht machbar ist (z.B. Datenbankmigration bereits durchgefuehrt), stattdessen das Forward-Fix-Verfahren dokumentieren. Jedes Release sollte einen Wiederherstellungspfad haben.

Validierung

Release-Strategie (kalender-/funktionsbasiert/hybrid) mit Begruendung dokumentiert
Meilensteintabelle enthaelt alle Phasen mit Daten: Entwicklung, Freeze, Stabilisierung, RC, Release
Feature-Freeze-Kriterien mit erlaubten/nicht erlaubten Aenderungstypen definiert
Funktionsprioritaetsliste kategorisiert (P0 muss / P1 sollte / P2 wuenschenswert)
RC-Prozess dokumentiert: Tagging-Konvention, Verteilung, Testzeitraum, Eskalation
Go/No-Go-Checkliste hat klare "Muss bestehen"- und "Sollte bestehen"-Abschnitte
Rollback-Plan enthaelt Ausloeser, Verfahren und Kommunikationsvorlage
RELEASE-PLAN.md (oder Aequivalent) erstellt und gespeichert
Zeitplan ist realistisch (Stabilisierung betraegt mindestens 15% des Gesamtzyklus)

Haeufige Stolperfallen

Keine Stabilisierungsphase: Direkt von Entwicklung zum Release gehen. Selbst eine 3-taegige Stabilisierungsphase entdeckt Probleme, die aktive Entwicklung maskiert
Umfangserweiterung nach Freeze: "Nur noch eine Funktion" nach Feature Freeze zulassen. Jede Post-Freeze-Ergaenzung setzt Tests zurueck und fuehrt zu Regressionsrisiko
P0-Risiken ignorieren: Nicht fruehzeitig eskalieren, wenn eine P0-Funktion gefaehrdet ist. Je frueher der Umfang angepasst wird, desto weniger Stoerung fuer den Zeitplan
RC fuer "kleine" Releases ueberspringen: Auch Minor-Releases profitieren von mindestens einem RC. Ein Tag RC-Tests ist guenstiger als ein Post-Release-Hotfix
Kein Rollback-Plan: Annehmen, dass das Release erfolgreich sein wird. Jeder Release-Plan sollte "Was wenn das schiefgeht?" vor der Veroeffentlichung beantworten
Kalenderdruck ueberwiegt Qualitaet: An einem Datum releasen, weil es versprochen wurde, trotz Nichtbestehens der Go/No-Go-Kriterien. Ein verspaetetes Release ist eine kleine Unannehmlichkeit; ein kaputtes Release ist ein Vertrauensbruch