semrel vs semantic-release vs goreleaser — Vergleich

Der Markt für Release-Automatisierung bietet mehrere etablierte Tools. Diese Seite gibt dir die Informationen, um das richtige zu wählen — oder von deinem bisherigen Tool zu migrieren.

semantic-release ist der Pionier der commit-getriebenen semantischen Versionierung und wird in tausenden Enterprise-Pipelines weltweit eingesetzt. semrel wurde entwickelt, um dieses Verhalten ohne den Runtime-Overhead zu replizieren.

Die Integration von semantic-release in eine Go-, Rust- oder C++-Pipeline erfordert:

# Jeder Pipeline-Job braucht das:
actions/setup-node@v4           # 30–60 Sekunden auf kalten Runnern
npm install -g semantic-release  # 28+ direkte Deps, 400+ transitive

In einer minimalen Alpine-Linux- oder Docker-in-Docker-Umgebung bedeutet das eine vollständige Node.js-Runtime in einen Container zu ziehen, der sonst nur ein Go-Toolchain enthält.

semrel ersetzt den gesamten Block durch:

curl -L https://github.com/SemRels/semrel/releases/latest/download/semrel_linux_amd64.tar.gz | tar -xz
./semrel release

semantic-release ist bekannt dafür, in Repositories mit vielen Tags und Branches zu zeitüberschreiten. Bei 460 Tags und 65 Branches wurden Ausführungszeiten von über 35 Minuten gemeldet — wegen sequenzieller Git-History-Traversierung und API-Aufrufe.

semrel ist kompiliertes Go — es traversiert git log und fragt Forge-APIs nebenläufig ab. Typische Ausführungszeit bei demselben Repository-Profil: unter 90 Sekunden.

semantic-release installiert bei jedem Pipeline-Lauf 28 direkte npm-Abhängigkeiten und hunderte transitiver Pakete. Das npm-Ökosystem war wiederholt Ziel von Supply-Chain-Angriffen.

semrel ist eine einzige statisch kompilierte Binärdatei. Es gibt keine node_modules, keine Laufzeit-Paketauflösung und keine transitive Abhängigkeits-Angriffsfläche.

Sowohl semrel als auch semantic-release unterstützen die Zuweisung von Commits zu Bump-Leveln anhand des Scopes. Das Feld scope in semrel ist optional — und unterstützt auch scope: false, um nur Commits ohne Scope zu matchen:

# semrel (.semrel.yaml)
rules:
  - type: deps
    scope: major
    bump: major
  - type: deps
    scope: minor
    bump: minor
  - type: deps
    scope: patch
    bump: patch
  - type: feat
    bump: minor

// semantic-release (package.json)
{
  "releaseRules": [
    { "type": "deps", "scope": "major", "release": "major" },
    { "type": "deps", "scope": "minor", "release": "minor" }
  ]
}

Äquivalente Konfigurationszuordnung:

Die ausführliche Schritt-für-Schritt-Migrationsanleitung findest du unter Von semantic-release zu semrel.

goreleaser und semrel lösen unterschiedliche Probleme und werden häufig zusammen eingesetzt.

Empfohlener kombinierter Workflow:

# GitHub Actions
- name: Nächste Version berechnen
  run: semrel release --dry-run --output json > semrel-output.json

- name: Artefakte bauen & verteilen
  uses: goreleaser/goreleaser-action@v6
  with:
    args: release
  env:
    GORELEASER_CURRENT_TAG: ${{ fromJson(steps.prev.outputs.json).nextVersion }}

Die ausführliche Schritt-für-Schritt-Migrationsanleitung findest du unter Von goreleaser zu semrel.

release-please (von Google) verwendet ein Pull-Request-First-Modell. Statt bei jedem Push zu releasen:

1. Sammelt es Commits in einem „Release-PR”
2. Ein Mensch merged den PR, um das Release auszulösen

Wähle release-please, wenn dein Team eine menschliche Freigabe vor jedem Release benötigt. Wähle semrel für vollständig automatisierte CI-Releases oder Nicht-GitHub-Forges.

Die ausführliche Schritt-für-Schritt-Migrationsanleitung findest du unter Von release-please zu semrel.

release-it ist ein beliebtes JavaScript-basiertes Release-Tool mit interaktivem CLI-Modus. Es unterstützt Conventional Commits, Changelogs, npm-Publishing und GitHub Releases.

release-it eignet sich gut für JavaScript/TypeScript-Projekte, die Node.js bereits in CI nutzen und eine interaktive Erfahrung wünschen. Wähle semrel für jeden Nicht-JS-Tech-Stack, air-gapped Umgebungen oder wenn Supply-Chain-Härtung wichtig ist.

changesets ist auf JavaScript/TypeScript ausgerichtet und erfordert, dass Entwickler manuell Changeset-Dateien erstellen, die ihre Änderungen beschreiben. Es liest Conventional Commits nicht automatisch.

Wähle semrel, wenn du keinen Entwickler-Overhead möchtest — einfach Conventional Commits schreiben und CI erledigt den Rest. changesets eignet sich für große JS-Monorepos, in denen eine feingranulare menschliche Kontrolle über den Versionssprung jedes Pakets bevorzugt wird.

Brauchst du kein Node.js in deiner Pipeline?
  → Ja   → semrel ✅
  → Nein → jedes Tool geeignet

Brauchst du Air-gap / vollständig Offline-CI?
  → Ja   → semrel ✅
  → Nein → jedes Tool geeignet

Brauchst du automatische Versionierung aus Commit-Nachrichten?
  → Ja   → semrel, semantic-release oder release-it
  → Nein → goreleaser (tag-basiert)

Brauchst du Scope-basierte Bump-Regeln (z. B. deps(major))?
  → Ja   → semrel oder semantic-release ✅
  → Nein → jedes Tool geeignet

Brauchst du Cross-Plattform Go-Binärkompilierung?
  → Ja   → goreleaser (kann mit semrel kombiniert werden)
  → Nein → semrel reicht

Möchtest du PR-Genehmigung vor dem Release?
  → Ja   → release-please
  → Nein → semrel ✅

Ist dein Projekt ausschließlich JavaScript/TypeScript?
  → Ja, mit interaktiven Releases → release-it
  → Ja, mit manueller Versionskontrolle → changesets
  → Nein → semrel ✅

Brauchst du GitLab-, Gitea- oder Bitbucket-Unterstützung?
  → Ja   → semrel ✅
  → Nein → jedes Tool geeignet

• Quick Start — dein erstes automatisiertes Release in 5 Minuten
• Konfigurationsreferenz
• Plugin-Übersicht
• Sicherheit & Supply-Chain