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
| Stage | Work |
|---|---|
| Branch preparation | Update versions, manpages, generated config, translations, chain parameters, release notes |
| Release candidate | Tag candidate, publish candidate artifacts, open testing meta-issue |
| Build attestation | Build with Guix and publish matching builder attestations |
| Codesigning | Produce detached signatures for macOS and Windows artifacts |
| Final release | Tag final version, publish artifacts, finalize notes, announce |
| Post-release | Mirror 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.confexamples if needed; - draft
doc/release-notes.mdon 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.sigsrepository; - 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.