Drasi version pinning - {project name}
Use this template as the durable versions.md artifact required by the Drasi
skill's "Pin via a versions manifest" non-negotiable rule. Every field must be
populated. CI gates parse this file to enforce pinned CLI version, apiVersion,
drasi-lib crate version, MCP spec version, and image digest.
Pinned components
| Component | Pinned value | Resolved on | Source of truth |
|---|---|---|---|
| Drasi Server image | ghcr.io/drasi-project/drasi-server@sha256:... |
YYYY-MM-DD | upstream image registry |
| Drasi platform release | 0.10.0 (or current) |
YYYY-MM-DD | drasi-project/drasi-platform releases |
| Drasi CLI version | 0.10.0 |
YYYY-MM-DD | drasi-platform releases |
| drasi-lib crate | 0.8.6 (AI-context baseline) or 0.9.0 (latest crates.io, Aug 2026; re-check crates.io before pinning) |
YYYY-MM-DD | drasi-context.yaml + crates.io |
| MCP spec version | 2025-03-26 |
YYYY-MM-DD | modelcontextprotocol spec |
| Source provider versions | per-provider list | YYYY-MM-DD | Drasi docs per provider |
Last-checked date
YYYY-MM-DD (must be ≤30 days old at PR merge time)
Refresh trigger
- Quarterly review
- On any reported upstream release
- Before any production deployment
Approved exceptions
Record any approved deviation from the AI-context current_stable_version (for
example, an explicit pin to a newer drasi-lib crate). Each exception MUST
include: component, pinned value, AI-context value, rationale, approver,
expiry date.
Cross-runtime compatibility
Populate this section only for projects that span more than one Drasi runtime form (for example, drasi-lib embedded in an edge service that feeds a Drasi Server hub, or Drasi for Kubernetes running alongside a drasi-lib worker). Single-runtime projects may skip this section.
| Coherence anchor | Recorded value | Rationale |
|---|---|---|
| Shared drasi-core version line (or commit SHA) | e.g. drasi-core 0.3.x or commit abc1234 |
Both runtimes resolve to this line; mixed-line projects are an explicit exception. |
| Cross-runtime apiVersion / result-contract assumption | e.g. apiVersion: v1 on both |
Field names and types in shared queries match across runtimes. |
| MCP spec coherence (only if either side exposes MCP) | e.g. 2025-03-26 on both |
Mixing MCP spec revisions across runtimes is a sev-2 design defect; resolve to one. |
Shared versions.md location |
path/URL | Single source of truth - no per-runtime drift in separate manifests. |
CI gate (mixed-runtime projects)
When this section is populated, CI MUST Also, verify:
- drasi-lib crate version and Drasi Server / Platform image digest resolve to compatible
drasi-core version lines per the project's compatibility statement above. The check
parses crate metadata (
cargo metadata --format-version 1 | jq -r ...) and the image digest's drasi-core SHA from release notes or the image's labels. - MCP spec revision is identical on every component that exposes an MCP Reaction or agent endpoint.
- If the project pins to an upcoming-API-break version of drasi-lib (the Replayable Sources / Resumable Reactions rewrite), the "Approved exceptions" table above explicitly records that decision and the migration timeline.
A mixed-runtime project that does not populate this section fails the version- manifest CI gate.
Notes
- The pinned image digest MUST be the result of
docker pull <image>followed bydocker inspect <image> | jq -r '.[0].RepoDigests[0]'- never a floating tag. - The pinned CLI version MUST be installed via an explicit release pin, not
via
curl | bashof an installer that pullsmain. - When the platform bumps
apiVersion, run the apiVersion migration playbook inbundles/sources/guide.mdand capture evidence intemplates/drasi-upgrade-evidence.mdbefore updating this manifest.