pjt222/submit-to-cran

Bei CRAN einreichen

Den vollstaendigen CRAN-Einreichungsworkflow von den Vorabpruefungen bis zur Einreichung ausfuehren.

Wann verwenden

• Paket ist fuer die erstmalige Veroeffentlichung auf CRAN bereit
• Eine aktualisierte Version eines bestehenden CRAN-Pakets wird eingereicht
• Nach CRAN-Prueferrueckmeldungen wird neu eingereicht

Eingaben

• Erforderlich: R-Paket, das den lokalen R CMD check mit 0 Fehlern und 0 Warnungen besteht
• Erforderlich: Aktualisierte Versionsnummer in DESCRIPTION
• Erforderlich: Aktualisierte NEWS.md mit Aenderungen fuer diese Version
• Optional: Frueherer CRAN-Prueferkommentar (fuer Wiedereinreichungen)

Vorgehensweise

Schritt 1: Version und NEWS pruefen

Version in DESCRIPTION verifizieren:

desc::desc_get_version()

Sicherstellen, dass NEWS.md einen Eintrag fuer diese Version enthaelt. Der Eintrag sollte benutzerseitige Aenderungen zusammenfassen.

Erwartet: Version folgt semantischer Versionierung. NEWS.md hat einen passenden Eintrag fuer diese Version.

Bei Fehler: Version mit usethis::use_version() aktualisieren (Auswahl: "major", "minor" oder "patch"). Einen NEWS.md-Eintrag mit benutzerseitigen Aenderungen hinzufuegen.

Schritt 2: Lokaler R CMD Check

devtools::check()

Erwartet: 0 Fehler, 0 Warnungen, 0 Hinweise (1 Hinweis bei Ersteinreichungen akzeptabel: "New submission").

Bei Fehler: Alle Fehler und Warnungen vor dem Fortfahren beheben. Das Pruefprotokoll unter <pkg>.Rcheck/00check.log fuer Details lesen. Hinweise sollten in cran-comments.md erlaeutert werden.

Schritt 3: Rechtschreibpruefung

devtools::spell_check()

Legitime Woerter zu inst/WORDLIST hinzufuegen (ein Wort pro Zeile, alphabetisch sortiert).

Erwartet: Keine unerwarteten Rechtschreibfehler. Alle markierten Woerter sind entweder korrigiert oder zu inst/WORDLIST hinzugefuegt.

Bei Fehler: Echte Rechtschreibfehler beheben. Fachbegriffe zu inst/WORDLIST hinzufuegen (ein Wort pro Zeile, alphabetisch sortiert).

Schritt 4: URL-Pruefung

urlchecker::url_check()

Erwartet: Alle URLs liefern HTTP 200 zurueck. Keine defekten oder weitergeleiteten Links.

Bei Fehler: Defekte URLs ersetzen. \doi{} fuer DOI-Links anstelle von rohen URLs verwenden. Links zu nicht mehr vorhandenen Ressourcen entfernen.

Schritt 5: Win-Builder-Pruefungen

devtools::check_win_devel()
devtools::check_win_release()

Auf E-Mail-Ergebnisse warten (in der Regel 15-30 Minuten).

Erwartet: 0 Fehler, 0 Warnungen fuer Win-builder release und devel. Ergebnisse kommen per E-Mail innerhalb von 15-30 Minuten an.

Bei Fehler: Plattformspezifische Probleme beheben. Haeufige Ursachen: unterschiedliche Compiler-Warnungen, fehlende Systemabhaengigkeiten, Pfadtrennzeichen-Unterschiede. Lokal beheben und erneut an Win-builder senden.

Schritt 6: R-hub-Pruefung

rhub::rhub_check()

Prueft auf mehreren Plattformen (Ubuntu, Windows, macOS).

Erwartet: Alle Plattformen bestehen mit 0 Fehlern und 0 Warnungen.

Bei Fehler: Wenn eine bestimmte Plattform fehlschlaegt, das R-hub-Build-Protokoll nach plattformspezifischen Fehlern durchsuchen. testthat::skip_on_os() oder bedingten Code fuer plattformabhaengiges Verhalten verwenden.

Schritt 7: cran-comments.md vorbereiten

cran-comments.md im Paketstammverzeichnis erstellen oder aktualisieren:

## R CMD check results
0 errors | 0 warnings | 1 note

* This is a new release.

## Test environments
* local: Windows 11, R 4.5.0
* win-builder: R-release, R-devel
* R-hub: ubuntu-latest (R-release), windows-latest (R-release), macos-latest (R-release)

## Downstream dependencies
There are currently no downstream dependencies for this package.

Fuer Aktualisierungen Folgendes einschliessen:

• Was sich geaendert hat (kurz)
• Antwort auf frueheres Prueferrueckmeldung
• Ergebnisse der Pruefung rueckwaertsgerichteter Abhaengigkeiten, falls zutreffend

Erwartet: cran-comments.md fasst die Pruefergebnisse aller Testumgebungen korrekt zusammen und erlaeutert alle Hinweise.

Bei Fehler: Wenn Pruefergebnisse zwischen Plattformen abweichen, alle Abweichungen dokumentieren. CRAN-Pruefer werden diese Angaben mit eigenen Tests vergleichen.

Schritt 8: Letzte Vorabpruefung

# Eine letzte Pruefung
devtools::check()

# Das gebaute Tarball verifizieren
devtools::build()

Erwartet: Abschliessender devtools::check() wird sauber bestanden. Ein .tar.gz-Tarball wird im uebergeordneten Verzeichnis erstellt.

Bei Fehler: Wenn ein letztes Problem auftaucht, es beheben und alle Pruefungen ab Schritt 2 erneut ausfuehren. Nicht mit bekannten Fehlern einreichen.

Schritt 9: Einreichen

devtools::release()

Fuehrt interaktive Pruefungen durch und reicht ein. Alle Fragen ehrlich beantworten.

Alternativ manuell unter https://cran.r-project.org/submit.html einreichen, indem das Tarball hochgeladen wird.

Erwartet: Bestaetigung per E-Mail von CRAN kommt innerhalb weniger Minuten an. Auf den Bestaetigunslink klicken, um die Einreichung abzuschliessen.

Bei Fehler: E-Mail auf Ablehnungsgruende pruefen. Haeufige Probleme: Beispiele zu langsam, fehlende \value-Tags, nicht portierbarer Code. Probleme beheben und erneut einreichen, dabei in cran-comments.md vermerken, was geaendert wurde.

Schritt 10: Nach der Einreichung

Nach der Annahme:

# Release taggen
usethis::use_github_release()

# Auf Entwicklungsversion hochsetzen
usethis::use_dev_version()

Erwartet: GitHub-Release mit dem angenommenen Versions-Tag erstellt. DESCRIPTION auf die Entwicklungsversion (x.y.z.9000) angehoben.

Bei Fehler: Wenn das GitHub-Release fehlschlaegt, es manuell mit gh release create erstellen. Wenn die CRAN-Annahme verzoegert ist, auf die Bestaetigung per E-Mail warten, bevor getaggt wird.

Validierung

• [ ] R CMD check liefert 0 Fehler, 0 Warnungen auf dem lokalen Rechner
• [ ] Win-builder besteht (release + devel)
• [ ] R-hub besteht auf allen getesteten Plattformen
• [ ] cran-comments.md beschreibt die Pruefergebnisse korrekt
• [ ] Alle URLs gueltig
• [ ] Keine Rechtschreibfehler
• [ ] Versionsnummer ist korrekt und inkrementiert
• [ ] NEWS.md ist aktuell
• [ ] DESCRIPTION-Metadaten sind vollstaendig und korrekt

Haeufige Stolperfallen

• Beispiele zu langsam: Aufwendige Beispiele in \donttest{} einschliessen. CRAN setzt Zeitlimits durch.
• Nicht-standardmaessige Datei-/Verzeichnisnamen: Dateien vermeiden, die CRAN-Hinweise ausloesen (.Rbuildignore pruefen)
• Fehlendes \value in Dokumentation: Alle exportierten Funktionen benoetigen ein @return-Tag
• Vignetten-Build-Fehler: Sicherstellen, dass Vignetten in einer sauberen Umgebung ohne .Renviron gebaut werden koennen
• DESCRIPTION-Titelformat: Muss Title Case sein, kein Punkt am Ende, kein "A Package for..."
• Pruefung rueckwaertsgerichteter Abhaengigkeiten vergessen: Fuer Aktualisierungen revdepcheck::revdep_check() ausfuehren

Beispiele

# Vollstaendiger Voreinreichungs-Workflow
devtools::spell_check()
urlchecker::url_check()
devtools::check()
devtools::check_win_devel()
rhub::rhub_check()
# Auf Ergebnisse warten...
devtools::release()

Verwandte Skills

• release-package-version - Versionserhoehung und Git-Tagging
• write-roxygen-docs - Dokumentation sicherstellen, die CRAN-Standards erfuellt
• setup-github-actions-ci - CI-Pruefungen, die CRAN-Anforderungen spiegeln
• build-pkgdown-site - Dokumentationswebsite fuer angenommene Pakete