Versioning

CodeCharter follows Semantic Versioning. This applies to the CLI, the VS Code extension, the GitHub Action, and the analysis schema.

Version structure

Three numbers MAJOR.MINOR.PATCH. All published releases use plain X.Y.Z version numbers.

What we guarantee per level

Patch

• Bug fixes or purely internal improvements only.
• No schema changes — a .ccr file that runs on X.Y.0 also runs on X.Y.5.
• No output format breakage; the JSON schema stays the same.
• Built-in rule packages unchanged in logic. Severity and description may be refined.

Patches are drop-in replacements.

Minor

• New features added additively: new built-in rule packages, new schema properties, new CLI options.
• No breaking changes to existing contracts. Existing .ccr files and CLI invocations continue to work.
• New built-in rules may produce new findings.

Major

• Breaking changes permitted: schema properties may be removed, output formats may change structurally, built-in rules may be removed.
• Major upgrades are a deliberate step accompanied by a migration guide.

Version pinning in CI

# Conservative: pin exactly
- uses: bochmann-software/codeguard@v1
  with:
    version: 1.0.12
    api-key: ${{ secrets.CODECHARTER_API_KEY }}

# Liberal: pin to major, use latest within that major
- uses: bochmann-software/codeguard@v1
  with:
    version: v1
    api-key: ${{ secrets.CODECHARTER_API_KEY }}

The version input supports prefix matching: v1 resolves to the newest 1.x.y release, v1.4 to the newest 1.4.y release, and v1.4.2 to exactly that version. The leading v is optional. If you omit version entirely, the default is latest, which resolves to the newest release regardless of major version — including a future 2.0.0 with breaking changes.

Recommendation for most teams: pin to the major version (for example version: v1). This gets you automatic bug fixes and features without breaking changes.

Note for teams pinning an exact version: a published release can be withdrawn (yanked), for example when a serious defect is found. A yanked version no longer resolves, so an exactly pinned version can stop working until you move to another release.

Version detection

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

The output is the bare version number followed by build metadata (+ and the commit hash). Include the full string when reporting an issue to support — it identifies the exact build.

The JSON output does not contain a version field. If you need to record which CodeCharter version produced a result, capture codecharter --version alongside the analysis.

Schema versioning

The analysis schema (properties on TypeModel, MethodModel, and other models) follows the same SemVer contract:

• Patch: no schema changes.
• Minor: new properties added additively.
• Major: existing properties may be removed.

Current state

You can see the current distribution version in the portal under Downloads. The supported versions per channel are listed under Channels.