geth/docs/release-support-policy.md

57 lines
2.3 KiB
Markdown
Raw Normal View History

2026-07-05 18:26:39 +02:00
# 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.
## 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.