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 aufX.Y.0läuft, läuft auch aufX.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.