Skip to content

Versionierung

SemVer für CLI, Extension, GitHub Action und Schema.

CodeCharter folgt Semantic Versioning. Das gilt für die CLI, die VS Code Extension, die GitHub Action und das Analyse-Schema.

Versionsstruktur

Drei Zahlen MAJOR.MINOR.PATCH. Alle veröffentlichten Releases tragen reine X.Y.Z-Versionsnummern.

Was wir pro Stufe versprechen

Patch

  • Nur Bugfixes oder rein interne Verbesserungen.
  • Keine Schema-Änderungen, eine .ccr, die auf X.Y.0 läuft, läuft auch auf X.Y.5.
  • Kein Output-Format-Bruch, das JSON-Schema bleibt gleich.
  • Eingebaute Regelpakete unverändert in Logik. Severity und Description dürfen sich verfeinern.

Patches sind drop-in.

Minor

  • Neue Features additiv: neue eingebaute Regelpakete, neue Schema-Properties, neue CLI-Optionen.
  • Kein Bruch bestehender Verträge. Bestehende .ccr-Files und CLI-Aufrufe funktionieren weiter.
  • Neue eingebaute Regeln können neue Findings produzieren.

Major

  • Breaking Changes erlaubt: Schema-Properties können wegfallen, Output-Formate können sich strukturell ändern, eingebaute Regeln können entfernt werden.
  • Major-Upgrades sind ein bewusster Schritt mit Migration-Guide.

Versions-Pinning in CI

# Konservativ: exakt pinnen
- uses: bochmann-software/codeguard@v1
  with:
    version: 1.0.12
    api-key: ${{ secrets.CODECHARTER_API_KEY }}

# Liberal: Major pinnen, neueste innerhalb des Majors
- uses: bochmann-software/codeguard@v1
  with:
    version: v1
    api-key: ${{ secrets.CODECHARTER_API_KEY }}

Der version-Input unterstützt Präfix-Matching: v1 löst auf das neueste 1.x.y-Release auf, v1.4 auf das neueste 1.4.y-Release und v1.4.2 exakt auf diese Version. Das führende v ist optional. Lassen Sie version ganz weg, gilt der Default latest. Der löst auf das neueste Release unabhängig vom Major auf, also auch auf eine künftige 2.0.0 mit Breaking Changes.

Empfehlung für die meisten Teams: Major pinnen, zum Beispiel version: v1. Damit bekommen Sie automatische Bugfixes und Features ohne Breaking Changes.

Hinweis für Teams, die exakt pinnen: ein veröffentlichtes Release kann zurückgezogen werden (yanked), etwa bei einem schweren Defekt. Eine zurückgezogene Version löst nicht mehr auf, eine exakt gepinnte Version kann also nicht mehr funktionieren, bis Sie auf ein anderes Release wechseln.

Versions-Erkennung

codecharter --version
# 1.0.12+8c18b2d6...

Die Ausgabe ist die reine Versionsnummer gefolgt von Build-Metadaten (+ und Commit-Hash). Geben Sie bei Support-Anfragen den kompletten String an, er identifiziert den exakten Build.

Der JSON-Output enthält kein Versionsfeld. Wenn Sie festhalten möchten, welche CodeCharter-Version ein Ergebnis erzeugt hat, erfassen Sie codecharter --version zusammen mit der Analyse.

Schema-Versionierung

Das Analyse-Schema (Properties an TypeModel, MethodModel und weiteren Modellen) folgt demselben SemVer-Vertrag:

  • Patch: keine Schema-Änderungen.
  • Minor: neue Properties additiv.
  • Major: alte Properties können wegfallen.

Aktueller Stand

Die aktuelle Distributions-Version sehen Sie im Portal unter Downloads. Die unterstützten Versionen pro Channel stehen unter Channels.