Release Package Version

Paketversion veroeffentlichen

Den vollstaendigen Versionsveroeffentlichungszyklus fuer ein R-Paket ausfuehren.

Wann verwenden

• Bereit zur Veroeffentlichung einer neuen Version (Fehlerbehebung, neues Feature oder einschneidende Aenderung)
• Nach CRAN-Akzeptanz ein entsprechendes GitHub-Release erstellen
• Post-Release-Entwicklungsversion einrichten

Eingaben

• Erforderlich: Paket mit veroeffentlichungsbereiten Aenderungen
• Erforderlich: Veroeffentlichungstyp: Patch (0.1.0 -> 0.1.1), Minor (0.1.0 -> 0.2.0) oder Major (0.1.0 -> 1.0.0)
• Optional: Ob bei CRAN eingereicht werden soll (Standard: nein, submit-to-cran-Skill separat verwenden)

Vorgehensweise

Schritt 1: Versionserhoehung bestimmen

Semantische Versionierung befolgen:

Erwartet: Der korrekte Erhoehungstyp (Patch, Minor oder Major) ist basierend auf der Art der Aenderungen seit der letzten Veroeffentlichung bestimmt.

Bei Fehler: Im Zweifelsfall git log seit dem letzten Tag ueberpruefen und jede Aenderung klassifizieren. Jede einschneidende API-Aenderung erfordert eine Major-Erhoehung.

Schritt 2: Version aktualisieren

usethis::use_version("minor")  # or "patch" or "major"

Dies aktualisiert das Version-Feld in DESCRIPTION und fuegt eine Ueberschrift zu NEWS.md hinzu.

Erwartet: DESCRIPTION-Version aktualisiert. NEWS.md hat einen neuen Abschnittstitel fuer die Veroeffentlichungsversion.

Bei Fehler: Wenn usethis::use_version() nicht verfuegbar ist, manuell das Version-Feld in DESCRIPTION aktualisieren und eine # packagename x.y.z-Ueberschrift zu NEWS.md hinzufuegen.

Schritt 3: NEWS.md aktualisieren

Die Veroeffentlichungsnotizen unter der neuen Versionsueuberschrift ausfuellen:

# packagename 0.2.0

## Neue Features
- `neue_funktion()` zur Datenverarbeitung hinzugefuegt (#42)
- Unterstuetzung fuer benutzerdefinierte Themes in `plot_results()` (#45)

## Fehlerbehebungen
- Absturz behoben wenn Eingabe nur NAs enthaelt (#38)
- Off-by-One-Fehler in `window_calc()` korrigiert (#41)

## Kleinere Verbesserungen
- Fehlermeldungen fuer ungueltige Eingabetypen verbessert
- Dokumentationsbeispiele aktualisiert

Issue-/PR-Nummern fuer die Rueckverfolgbarkeit verwenden.

Erwartet: NEWS.md enthaelt eine vollstaendige Zusammenfassung benutzersichtbarer Aenderungen nach Kategorien geordnet, mit Issue-/PR-Nummern fuer die Rueckverfolgbarkeit.

Bei Fehler: Wenn Aenderungen schwer zu rekonstruieren sind, git log --oneline v<vorgaenger>..HEAD verwenden um alle Commits seit der letzten Veroeffentlichung aufzulisten und zu kategorisieren.

Schritt 4: Abschlusspruefungen

devtools::check()
devtools::spell_check()
urlchecker::url_check()

Erwartet: devtools::check() gibt 0 Fehler, 0 Warnungen und 0 Anmerkungen zurueck. Rechtschreib- und URL-Pruefung finden keine Probleme.

Bei Fehler: Alle Fehler und Warnungen vor der Veroeffentlichung beheben. Falsch-positive Woerter zu inst/WORDLIST fuer die Rechtschreibpruefung hinzufuegen. Fehlerhafte URLs ersetzen.

Schritt 5: Veroeffentlichung committen

git add DESCRIPTION NEWS.md
git commit -m "Release packagename v0.2.0"

Erwartet: Ein einzelner Commit der die Versionserhoehung in DESCRIPTION und die aktualisierte NEWS.md enthaelt.

Bei Fehler: Wenn andere nicht-committete Aenderungen vorhanden sind, nur DESCRIPTION und NEWS.md stagen. Veroeffentlichungs-Commits sollten nur versionsbezogene Aenderungen enthalten.

Schritt 6: Das Release taggen

git tag -a v0.2.0 -m "Release v0.2.0"
git push origin main --tags

Erwartet: Annotierter Tag v0.2.0 erstellt und zum Remote gepusht. git tag -l zeigt den Tag lokal; git ls-remote --tags origin bestaetigt ihn auf dem Remote.

Bei Fehler: Wenn der Push fehlschlaegt, Schreibzugriff pruefen. Wenn der Tag bereits existiert, verifizieren dass er auf den korrekten Commit zeigt mit git show v0.2.0.

Schritt 7: GitHub-Release erstellen

gh release create v0.2.0 \
  --title "packagename v0.2.0" \
  --notes-file NEWS.md

Oder verwenden:

usethis::use_github_release()

Erwartet: GitHub-Release erstellt mit Veroeffentlichungsnotizen sichtbar auf der Releases-Seite des Repositorys.

Bei Fehler: Wenn gh release create fehlschlaegt, sicherstellen dass die gh-CLI authentifiziert ist (gh auth status). Wenn usethis::use_github_release() fehlschlaegt, das Release manuell auf GitHub erstellen.

Schritt 8: Entwicklungsversion setzen

Nach der Veroeffentlichung zur Entwicklungsversion wechseln:

usethis::use_dev_version()

Dies aendert die Version zu 0.2.0.9000 als Kennzeichnung fuer Entwicklung.

git add DESCRIPTION NEWS.md
git commit -m "Begin development for next version"
git push

Erwartet: DESCRIPTION-Version ist jetzt 0.2.0.9000 (Entwicklungsversion). NEWS.md hat eine neue Ueberschrift fuer die Entwicklungsversion. Aenderungen sind zum Remote gepusht.

Bei Fehler: Wenn usethis::use_dev_version() nicht verfuegbar ist, die Version manuell zu x.y.z.9000 in DESCRIPTION aendern und eine # packagename (Entwicklungsversion)-Ueberschrift zu NEWS.md hinzufuegen.

Validierung

• Version in DESCRIPTION stimmt mit beabsichtigter Veroeffentlichung ueberein
• NEWS.md hat vollstaendige, genaue Veroeffentlichungsnotizen
• R CMD check besteht
• Git-Tag stimmt mit Version ueberein (z.B. v0.2.0)
• GitHub-Release existiert mit Veroeffentlichungsnotizen
• Post-Release-Entwicklungsversion gesetzt (x.y.z.9000)

Haeufige Stolperfallen

• Vergessen Tags zu pushen: git push allein pusht keine Tags. --tags verwenden oder git push origin v0.2.0
• NEWS.md-Format: Markdown-Ueberschriften im von pkgdown/CRAN erwarteten Format verwenden
• Falschen Commit taggen: Immer nach dem Versionserhoehungs-Commit taggen, nicht davor
• CRAN-Version existiert bereits: CRAN akzeptiert keine bereits veroeffentlichte Version. Immer inkrementieren.
• Entwicklungsversion in der Veroeffentlichung: Nie eine .9000-Version bei CRAN einreichen

Verwandte Skills

• submit-to-cran -- CRAN-Einreichung nach Versionsveroeffentlichung
• create-github-release -- Allgemeine GitHub-Release-Erstellung
• setup-github-actions-ci -- Loest pkgdown-Neubau bei Release aus
• build-pkgdown-site -- Dokumentationsseite spiegelt neue Version wider