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