PatchPatrol
Get Started

Release and Versioning

Find the public release contract, version source of truth, and upgrade references.

Release and Versioning

PatchPatrol operators use SemVer release artifacts aligned across three files and tags.

Source of truth

The release contract is documented in:

All three must match at release time.

Historical repository tags v1.0, v1.1, v1.2, and v1.3 are milestone archive markers, not SemVer product releases. Production-style pinning starts with three-part release tags such as v1.3.0.

What to expect in a release

  • Public source release notes are tracked in CHANGELOG.md.
  • Versioning follows MAJOR.MINOR.PATCH:
    • MAJOR: breaking change to documented behavior or compatibility.
    • MINOR: backward-compatible additions.
    • PATCH: fixes and docs-only improvements.
  • Registry image names are:
    • registry.patchpatrol.ai/patchpatrol
    • registry.patchpatrol.ai/patchpatrol-semantic

Most clients should use latest in CI. Use vX.Y.Z only when you need to stay on a specific patch version. Patch tags such as vX.Y.Z remain immutable. Authentication is required before pulling images.

Use these links when communicating support and upgrade decisions:

Practical upgrade flow

  1. Confirm the target version in policy and changelog.
  2. Keep latest in the review job if you want automatic uptake of review improvements.
  3. If you need a specific patch version, update the review job tag to vX.Y.Z.
  4. Run readiness checks and one artifact-first GitLab merge request path before wider rollout.

Notes for operators

  • latest is the recommended default when you want the most recent review improvements.
  • Rollback is handled by selecting the required vX.Y.Z image tag and re-validating the same job path.
  • If an upgrade requires changing provider endpoints or model behavior, run a full onboarding verification again after the version change.

Next step

If you are moving from trial setup to regular usage, start with:

On this page