eric/geth
Watch
1
0
Fork
You've already forked geth
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
geth/docs/release-support-policy.md

3.3 KiB
Raw Blame History

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 x86_64 and arm64
  • 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.
  • Every archive must have a published SHA-256 checksum, and the release must include SHA256SUMS plus the platform installer entrypoints.
  • Packaged archives must include README, docs, and license files.
  • Packaged binaries must be checksum-verified and smoke-tested from the archive through the same installer path documented for users.
  • Installers must never initialize a home, create trust state, or start a user service; geth daemon install remains a separate explicit action.
  • Any breaking changes must be called out in release notes.