# Submit To Cran > 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. - Skill: `pjt222/submit-to-cran-11` (Agent Skill) - Install (CLI): `npx skillmds@latest add pjt222/submit-to-cran-11` - Raw SKILL.md: https://api.skillmd.com/api/skills/pjt222/submit-to-cran-11/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - License: MIT - Author: pjt222 (https://skillmd.com/u/pjt222) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/pjt222/submit-to-cran-11 --- # 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: ```r 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 ```r 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 `.Rcheck/00check.log` fuer Details lesen. Hinweise sollten in cran-comments.md erlaeutert werden. ### Schritt 3: Rechtschreibpruefung ```r 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 ```r 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 ```r 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 ```r 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: ```markdown ## 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 ```r # 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 ```r 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: ```r # 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 ```r # 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