# Release And Support Policy

`geth` is pre-deployment software. Until the first deployment tag, releases are
pre-releases intended for dogfood and controlled automation only.

## Supported Platforms

Release archives are built for:

- Linux x86_64
- macOS
- Windows x86_64

The daemon and control CLI are supported as a single `geth` executable on those
platforms. Service installation remains user-level only: systemd user units on
Linux, launchd user agents on macOS, and per-user scheduled tasks on Windows.
`geth` does not install or require system services.

Overlay interface activation is platform-dependent and may require local host
entitlements such as Linux `CAP_NET_ADMIN`, macOS network-extension approval, or
Windows Wintun setup. See `docs/overlay-platforms.md`.

## Compatibility

Before the first deployment tag, breaking changes are allowed when they reduce
long-term risk and are reflected in `docs/production-readiness-roadmap.md`.
After the first deployment tag:

- Stable commands and `--json` fields follow `docs/compatibility.md`.
- Experimental commands may change with a release note and migration path.
- Prototype commands may change, be replaced, or be removed before a stable
  guarantee is made.
- Local SQLite schema changes require ordered migrations and upgrade tests.
- Signed operation formats must not be changed without a new version or
  explicit migration behavior.

## Upgrade And Rollback

Before the first deployment tag, upgrade tests use synthetic pre-release homes
that exercise the same on-disk contracts as tagged fixtures: config, SQLite
schema, signed keychain/auth logs, CAS metadata, and peer-card metadata. Once a
tagged pre-release exists, its fixture home must be kept and migrated by the
current test suite.

Store migrations are forward-only. A newer daemon may upgrade `geth.sqlite` in
place, so rollback means restoring a backup made before the upgrade or using a
copied fixture home. Downgrading a migrated home with an older binary is not a
supported recovery path unless a release note explicitly says so.

## Security Updates

Security fixes should be released as soon as practical after validation. The
project runs CI, RustSec audit, CodeQL, dependency review, and Dependabot, but
those checks do not replace manual review of Iroh transport, authorization,
host-opening, and cryptographic boundaries.

Bearer tokens, private SSH keys, and resource secrets must not be copied into
release artifacts, logs, examples, or support bundles. SSH keys remain local
admin trust anchors and are never a geth transport fallback.

## Release Checklist

For a tagged release:

- CI must pass formatting, check, tests, and clippy.
- Security workflows must pass or have an explicit documented exception.
- Release archives must be built by `.github/workflows/release.yml`.
- Packaged archives must include README, docs, and license files.
- Packaged binaries must be smoke-tested from the archive.
- Any breaking changes must be called out in release notes.