Skip to Content
DevelopersRelease Process

Release Process

Tidecoin releases are prepared through version updates, release notes, signed tags, Guix reproducible builds, attestations, detached signatures for signed platform artifacts, and publication through the official release channel.

This page is a contributor overview. The source of truth is ../tidecoin/doc/release-process.md.

Release Stages

StageWork
Branch preparationUpdate versions, manpages, generated config, translations, chain parameters, release notes
Release candidateTag candidate, publish candidate artifacts, open testing meta-issue
Build attestationBuild with Guix and publish matching builder attestations
CodesigningProduce detached signatures for macOS and Windows artifacts
Final releaseTag final version, publish artifacts, finalize notes, announce
Post-releaseMirror release notes into docs and track follow-up issues

Version and Notes

Before a major or minor release:

  • update version values in CMakeLists.txt;
  • set release-candidate state correctly;
  • update manpages after rebuilding binaries;
  • update generated tidecoin.conf examples if needed;
  • draft doc/release-notes.md on the release branch.

Release notes should describe user-facing changes, upgrade requirements, deprecations, known issues, and security-relevant changes without exposing embargoed vulnerability details prematurely.

Tagging

Release candidates and final releases are tagged from the repository root with signed git tags:

VERSION="1.0.1" git fetch origin --tags git tag -s "v${VERSION}" -m "Tidecoin ${VERSION}" git push origin "v${VERSION}"

Use the real version and branch procedure from doc/release-process.md.

Guix Builds

Guix reproducible builds allow multiple builders to independently produce and attest to matching artifacts. Builders work with:

  • the Tidecoin source repo;
  • a guix.sigs repository;
  • detached signature repositories where codesigning is involved;
  • contrib/guix/ build and verify tooling.

Do not publish release binaries as final until the expected builder and codesigning checks are complete.

User Verification Surface

Release publication should give users:

  • version tag;
  • source commit;
  • release notes;
  • checksums;
  • signatures or attestations;
  • platform-specific artifacts;
  • upgrade notes and compatibility warnings.

The docs reference page should mirror release notes, but the repository release notes remain canonical while a release is being prepared.

See also: Contributing, Security Reporting, Reference / Release Notes, Node Upgrades.

Last updated on