Release Workflow

Lattice has separate release lanes for the server image, node-agent binary, SDK contract, docs, and plugin index.

Server image

lattice-server publishes to GHCR from its container workflow.

ghcr.io/latticenet/lattice-server:latest
ghcr.io/latticenet/lattice-server:alpha
ghcr.io/latticenet/lattice-server:<version>
ghcr.io/latticenet/lattice-server:beta

Image publication is tag-driven. The moving latest git tag publishes :latest, the moving alpha git tag publishes :alpha, the moving beta git tag publishes :beta, and stable v* tags publish immutable version tags. There is no main, branch, sha, or hash-string image channel. Use a version tag or digest for unattended production deployments when you do not want a moving channel.

GitHub Container Registry lists package versions by digest. A tagged manifest appears with tags such as latest or alpha; historical untagged digests cannot be renamed after the fact. The server repository disables buildx provenance/SBOM attestation manifests for the image workflow and runs package cleanup to prune old tags: [] container versions. Cleanup protects the architecture child digests referenced by the active latest, alpha, and beta manifest lists, then removes stale untagged versions.

Every server image exposes its build metadata through:

curl -fsS https://lattice.example.com/api/version

The dashboard also shows the same information under Settings -> About.

Node-agent binaries

lattice-node-agent publishes Linux binaries from v* tags:

lattice-agent-linux-amd64
lattice-agent-linux-arm64
SHA256SUMS

Release tags inject the binary version with:

-X main.version=$VERSION

The binary must report the same value used by the server update policy:

lattice-agent -version

Create an agent release

cd lattice-node-agent
NEXT_AGENT=v0.2.10-alpha.1
git tag -a "$NEXT_AGENT" -m "lattice-node-agent $NEXT_AGENT"
git push origin "$NEXT_AGENT"

The release workflow builds Linux and Darwin artifacts, publishes SHA checksums, and attaches everything to the GitHub Release.

After it completes, get the digest:

curl -fsSL --proto '=https' --tlsv1.2 "https://github.com/LatticeNet/lattice-node-agent/releases/download/${NEXT_AGENT}/SHA256SUMS"

The normal dashboard flow is official-release mode:

target version: latest or 0.3.3
binary URL: empty
SHA-256: empty
install path: empty unless the node is intentionally non-standard
service name: lattice-agent.service

The server resolves the configured official release repo, maps the target node OS/arch to an artifact, reads SHA256SUMS, and writes the concrete version, URL, and digest into the approval plan. Custom binary URL + SHA-256 remains available for emergency or forked artifacts, but both fields must be provided together and the URL must be HTTPS.

latest is an operator intent, not the immutable artifact identity. At plan time it is resolved to the current v* release and the approval carries the resolved version plus SHA-256. A successful update records the applied version; the live source of truth is still the next node heartbeat's reported agent_version.

The server resolves latest from GitHub's release list, skips drafts and prereleases, and caches release-list and SHA256SUMS metadata. Explicit update plans become immutable after the release URL and digest are resolved. Authenticated GitHub access can still be useful for operator automation, but it is not required for the official agent update flow.

Because the resolver only ever selects a stable vX.Y.Z, a stable lane that lags the fleet has a visible consequence: planning refuses the resulting downgrade, once per node per evaluation. That refusal is the policy working, not a fault — but it is also the signal that the stable lane needs a cut. Agent update planning never downgrades a node silently; moving a node back to an older lane must be an explicit operator decision with a reviewed artifact and a rollback plan.

Compatibility discipline

Ordinary server, dashboard, agent, SDK, and official plugin releases must remain backward compatible across at least one rolling deployment window.

• Server endpoints may add fields but must not remove or repurpose fields used by the current dashboard or agents without a version gate.
• Dashboard changes must tolerate older server responses and older node runtime reports.
• Agent changes must tolerate an older server until the next server deploy, and server code must tolerate older agents until they report the new runtime capability.
• Plugin manifests may add interfaces/views, but existing signed interface names and builtin component keys must keep working until a documented migration.
• Breaking behavior requires a release note, a rollback path, and an explicit capability/version check rather than relying on "latest".

SDK order

If server or agent code depends on a new shared model, publish the lattice-sdk tag first. Downstream CI may use workspace replaces, but users who clone one repository should not need an unpublished SDK tag.

cd lattice-sdk
NEXT_SDK=v0.2.18 # replace with the next SDK tag after the latest published baseline
git tag -a "$NEXT_SDK" -m "lattice-sdk $NEXT_SDK"
git push origin main
git push origin "$NEXT_SDK"

cd ../lattice-server
GOPROXY=direct GOSUMDB=off GOWORK=off go get "github.com/LatticeNet/lattice-sdk@$NEXT_SDK"

cd ../lattice-node-agent
GOPROXY=direct GOSUMDB=off GOWORK=off go get "github.com/LatticeNet/lattice-sdk@$NEXT_SDK"

Plugin index

The plugin index is static, but the current public catalog remains draft until the top-level index signature is populated. Updating it should not imply remote install or runner activation. Marketplace install remains blocked until verification, lifecycle registration, and runner sandbox maturity are all in place.