diff --git a/README.md b/README.md index e04c21d..c75c3cc 100644 --- a/README.md +++ b/README.md @@ -651,6 +651,8 @@ GitHub Actions workflows live under `.github/workflows/`: - `release.yml` builds release archives for Linux, macOS, and Windows, includes README/docs/license files, smoke-tests the packaged binary from the archive, uploads artifacts, and publishes them on `v*` tags or manual dispatch. +- `docs/release-support-policy.md` defines supported platforms, compatibility + expectations, security update handling, and the user-level service boundary. - `.github/dependabot.yml` opens weekly Cargo and GitHub Actions update PRs. Local equivalents remain: diff --git a/docs/production-readiness-roadmap.md b/docs/production-readiness-roadmap.md index c85ce3f..d391b60 100644 --- a/docs/production-readiness-roadmap.md +++ b/docs/production-readiness-roadmap.md @@ -311,12 +311,12 @@ Goal: make first deployment the start of a controlled compatibility story. metadata, and peer cards. - `[ ]` Rollback expectations are documented. -- `[ ]` Publish release and support policy. +- `[x]` Publish release and support policy. Acceptance criteria: - - `[ ]` Supported platforms are listed. - - `[ ]` Breaking-change policy is documented. - - `[ ]` Security update expectations are documented. - - `[ ]` User-service installation remains user-level only. + - `[x]` Supported platforms are listed. + - `[x]` Breaking-change policy is documented. + - `[x]` Security update expectations are documented. + - `[x]` User-service installation remains user-level only. ## Phase 10: Pre-Deployment Dogfood Gate diff --git a/docs/release-support-policy.md b/docs/release-support-policy.md new file mode 100644 index 0000000..35c8ce3 --- /dev/null +++ b/docs/release-support-policy.md @@ -0,0 +1,57 @@ +# 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.