Skip to content

RELEASE.md

Latest commit

 

History

History
38 lines (27 loc) · 1.83 KB

RELEASE.md

File metadata and controls

38 lines (27 loc) · 1.83 KB
Raw

Release Process

StellarHunts uses Semantic Versioning and tags to trigger releases.

Cutting a release

  1. Decide the next version: bump MAJOR for breaking changes, MINOR for new features, PATCH for bug fixes.
  2. Create and push the annotated tag: 
    git tag -a vX.Y.Z -m "Release vX.Y.Z"
git push origin vX.Y.Z
  3. The Release workflow will automatically:
    • Build the frontend, backend, and on-chain (Soroban) artifacts
    • Generate a release changelog from conventional-commit messages
    • Attach the compiled .wasm contract files to a GitHub Release

Conventional commits

Commit messages prefixed with feat:, fix:, docs:, refactor:, test:, ci:, chore:, or style: are grouped under those headings in the release notes.

Hotfixes

For urgent patches, branch from the latest tag, fix, and tag a new PATCH version.

Artifact Retention and Provenance Policy

Artifact Retention

  • Release Artifacts: Release binaries, built assets, and container images associated with official releases are retained indefinitely.
  • CI Build Artifacts: Intermediate build artifacts generated during pull request validation and daily CI runs are retained for 90 days.

Provenance and Verification

  • Verifiable Builds: All production-grade build artifacts must be generated via the official CI/CD pipeline (release.yml).
  • Chain of Custody: Releases use GitHub Actions with OpenID Connect (OIDC) to verify build origin. We aim for SLSA compliance, ensuring that build recipes are verifiable, tamper-resistant, and traced back to the exact commit SHA in the repository.
  • On-chain Contracts: Contract .wasm binaries attached to releases must match the output generated by reproducible Soroban builds from the tagged source code.