Skyhook uses independent versioning for three components, all following Semantic Versioning:
- Operator - Kubernetes operator that manages Skyhook resources
- Agent - Container that executes package operations on nodes
- Chart - Helm chart for deploying the operator
- NOTE: the versioning of the chat also includes versioning of the expected agent version.
- NOTE: If changing either the operator or agent this will generally include a chart release too.
operator/v{version} # Operator releases
agent/v{version} # Agent releases
chart/v{version} # Chart releases- Independent versioning with their own release cycles
- Semantic versioning: MAJOR.MINOR.PATCH
- Compatibility: Maintained through well-defined interfaces
- Independent from operator/agent (starting at v0.8.0 these will start to diverge in version number)
- Chart version (
version): Tracks chart template/config changes - App version (
appVersion): Recommended stable operator version
example:
version: v1.0.0 # Chart version (independent)
appVersion: v0.7.0 # Recommended operator version# values.yaml
image:
tag: "" # Empty = defaults to Chart.AppVersion
# Template renders as:
image: "ghcr.io/nvidia/skyhook/operator:0.7.0"- You can specify either a tag or a digest for images.
- If both are provided, the digest takes precedence and determines the image pulled. The rendered image reference may display as
:tag@sha256:..., but the digest controls selection.
Skyhook uses release branches to manage patches and maintenance releases:
release/v0.8.x # Contains operator v0.8.0 + agent v6.3.0 + chart v0.8.x
release/v0.9.x # Contains operator v0.9.0 + (agent v6.3.0*) + chart v0.9.x
release/v0.10.x # Contains operator v0.10.0 + (agent v6.3.0*) + chart v0.10.x*Agent versions may not change every release - operator drives the release cycle
- Operator-centric releases - most releases are driven by operator features and bugs
- Chart defines compatibility - each branch contains a tested, compatible set of all components
- Agent follows operator - agent changes typically only require chart patch releases
- Simplified patches - fix bugs in the context of the full integrated system
- Connected git history - preserves relationships between operator, agent, and chart changes
- Main development happens on
mainbranch - Release preparation creates
release/v{MAJOR.MINOR}.xbranch (typically driven by operator changes) - Patch releases are developed and tagged from release branches
- Agent-only changes usually result in chart patch releases (no new release branch)
- Critical fixes may be backported from
mainto release branches
The operator supports Go module imports for external projects:
# External projects can import the operator
go get github.com/NVIDIA/nodewright/operator@v0.8.0Module mapping: Tag operator/v0.8.0 maps to module github.com/NVIDIA/nodewright/operator@v0.8.0
# Check deployed versions
kubectl get deployment -n skyhook -o jsonpath='{.items[0].spec.template.spec.containers[0].image}'
helm list -n skyhook
# Override operator version
helm install skyhook ./chart --set controllerManager.manager.image.tag="0.8.0"
# Check release branches
git branch -r | grep release/For step-by-step instructions on how to release components, see release-process.md.
CI/CD triggers on git tags:
operator/vx.y.z→ publishes operator imageagent/vx.y.z→ publishes agent imagechart/vx.y.z→ publishes helm chart
Chart versioning:
- PATCH: Bug fixes, docs
- MINOR: New features, config options
- MAJOR: Breaking changes to chart, or compatibility with agent or operator.