Maturity & Support Policy
spore.host is a suite of separately-versioned tools, and they are not all at the same stage. This page states, in one place, how mature each piece is, what compatibility you can rely on, which platforms are supported, and how we handle deprecations — so you can decide what to build on and what to pin.
Maturity levels
| Badge | Meaning |
|---|---|
| Stable | Interface is settled and actively supported. Changes are additive or follow the deprecation process below. Not the same as 1.0/GA — see Versioning. |
| Beta | Usable and supported, but the interface may still change with notice. |
| Experimental | Early / prototype. May change or break without a deprecation window. Validate against your own workload before relying on it. |
| Planned | On the roadmap, not built yet. |
Component status
The six core tools are Stable: their commands and flags are settled and we maintain them actively. They are all still pre-1.0 (v0.x) — see Versioning for exactly what that means for breaking changes.
| Component | Status | Latest | Notes |
|---|---|---|---|
| truffle | Stable | v0.46.0 | Instance discovery, quotas, spot/capacity search (read-only). |
| spawn | Stable | v0.91.x | Launch + full lifecycle management. |
| spored | Stable | ships with spawn | In-instance lifecycle daemon; built and released with spawn. |
| lagotto | Stable | v0.50.0 | Capacity watcher. |
| spore-bot | Stable | continuous | Slack/Teams control. Deployed continuously (not tag-released). |
| MCP server | Stable | v0.36.x | Read/manage tools for AI assistants — no launch, by design. |
| Plugin registry | Stable | per-plugin | Each plugin is versioned independently in its plugin.yaml; official plugins are signature-verified. |
Beta and experimental surfaces
Some capabilities inside otherwise-Stable tools are less settled. These are called out where they appear in the docs; the list below is the canonical index.
| Surface | Status | Where |
|---|---|---|
| HTTP API + Python SDK | Beta | The SDK is the supported entry point; the underlying HTTP API may change. See Python SDK. |
| Workflow adapters (Nextflow, WDL, CWL, Snakemake, Airflow) | Experimental | All five are early — two pre-1.0 prototypes and three v0.1.0 initial releases. Read the status & compatibility matrix before relying on one. |
| Pipeline stage streaming (tcp/grpc/zmq) | Experimental | Operationally involved; prefer the S3 handoff. See Spawn pipelines. |
| Per-event notification filtering | Planned | See Lifecycle Notifications. |
If a page and this table ever disagree, the more conservative (less mature) label wins — please report it.
Versioning — what you can rely on
Every spore.host tool follows Semantic Versioning 2.0.0 and keeps a Keep a Changelog-format CHANGELOG.md. User-facing changes land in the changelog in the same change that makes them.
All tools are currently pre-1.0 (v0.x). Under SemVer's pre-1.0 rules, that changes what a version bump means:
| Bump | Pre-1.0 meaning (today) | Post-1.0 meaning (future) |
|---|---|---|
MAJOR (X) | — (still 0) | Breaking change |
MINOR (0.Y) | Breaking changes or new features | Backward-compatible feature |
PATCH (0.0.Z) | Backward-compatible fix | Backward-compatible fix |
The practical rule while we're pre-1.0: a breaking change bumps the MINOR version. So if you depend on exact CLI behavior in automation, pin to a MINOR series (e.g. spawn 0.91.x) and read the changelog's Changed/Removed/ Deprecated sections before moving to a new minor.
- Plugins version independently — each plugin's
version:in itsplugin.yamlfollows SemVer per plugin (a breaking change to a plugin's inputs/behavior bumps its version). The registry itself is not versioned as a whole. - Go library consumers (e.g. importing truffle as a package): a breaking exported-signature change is treated as a breaking bump (pre-1.0 ⇒ MINOR).
Platform support
Where the CLIs run
The truffle, spawn, and lagotto binaries are published for:
| OS | amd64 | arm64 |
|---|---|---|
| macOS | ✅ | ✅ |
| Linux | ✅ | ✅ |
| Windows | ✅ | ✅ |
Install via Homebrew, Scoop, .deb/.rpm, or a manual download. On Windows, run the CLIs under WSL2 for the smoothest experience.
What spawn can launch
- Linux instances — Amazon Linux 2023 (the auto-selected default), Amazon Linux 2, and Ubuntu AMIs. spored installs via user-data at launch.
- Windows instances — supported via SSM-first launch and connect, with spored running as a native Windows service. (The headless launcher path used by lagotto is Linux-only.)
- GPU — spawn auto-selects a GPU AMI for GPU instance types; truffle discovers GPU families and their price/quotas. See GPU training.
- EFA / MPI —
--efaenables Elastic Fabric Adapter on supported instance types with an auto-configured security group and cluster placement group. See MPI clusters.
Deprecation & support
We remove things carefully and telegraph it:
- Deprecations are announced in the changelog under a
Deprecatedheading in the release that introduces them, and the CLI itself prints a deprecation notice when you use the old form. - The old form keeps working as an alias for a transition period rather than breaking immediately — for example
truffle searchnow points totruffle find, and severalspawnsubcommands moved underspawn ami …andspawn sweep …while the old names still run. - Removal happens in a later MINOR release (pre-1.0), and is listed under
Removedin that release's changelog. Pinning to a MINOR series (above) means a removal never surprises you.
We do not yet publish a fixed end-of-life schedule (e.g. "supported for N minors"). While we're pre-1.0, the latest release of each tool is the supported one; fixes land on the latest and are shipped as a new PATCH or MINOR. If you need a longer support commitment for an institutional deployment, that's a good thing to raise in the deployment packet conversation with your admin — or ask us.