---

name: submit-to-cran description: > Vollstaendiges Verfahren zur Einreichung eines R-Pakets bei CRAN, einschliesslich Vorpruefungen (lokal, win-builder, R-hub), Vorbereitung der cran-comments.md, URL- und Rechtschreibpruefung sowie der eigentlichen Einreichung. Deckt Ersteinreichungen und Aktualisierungen ab. Verwenden, wenn ein Paket fuer die erstmalige Veroeffentlichung auf CRAN bereit ist, eine aktualisierte Version eingereicht werden soll oder nach CRAN-Prueferrueckmeldungen neu eingereicht wird. locale: de source_locale: en source_commit: 6f65f316 fence_basis_commit: 6f65f316 translator: claude-opus-4-6 translation_date: 2026-03-16 license: MIT allowed-tools: Read Write Edit Bash Grep Glob metadata: author: Philipp Thoss version: "1.0" domain: r-packages complexity: advanced language: R tags: r, cran, submission, release, publishing

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

# One last check
devtools::check()

# Verify the built tarball
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:

# Tag the release
usethis::use_github_release()

# Bump to development version
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

# Full pre-submission workflow
devtools::spell_check()
urlchecker::url_check()
devtools::check()
devtools::check_win_devel()
rhub::rhub_check()
# Wait for results...
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