q-blog/docs/RELEASING.md

Releasing — Q-Blog

This summarizes the practical steps we use today to publish a release via Gitea and attach versioned artifacts.

Pre-flight

• Ensure CI is green on the branch to release.
• Verify locally:
  • Format first: npm run format:fix
  • npm run typecheck && npm run lint:full && npm run test:run
  • Optional production build: npm run build

Create archives

Use our helper to produce versioned source and dist archives under release/:

bash scripts/release/build-archive.sh --with-build --outdir release --name q-blog

This creates:

• release/q-blog-vX.Y.Z-src.zip (always)
• release/q-blog-vX.Y.Z-dist.zip (if dist/ exists)

Tag

If the package.json version is already correct, tag it:

git tag -a vX.Y.Z -m "Q-Blog vX.Y.Z"
git push origin --tags

Or bump + tag via script:

bash scripts/release/bump-and-tag.sh X.Y.Z "Q-Blog vX.Y.Z"

Create/Update Gitea Release

With .gitea.env configured, run:

bash scripts/tracker/with_env.sh .gitea.env \
  bash scripts/release/create-gitea-release.sh X.Y.Z \
  --title "Q-Blog vX.Y.Z" \
  --notes docs/RELEASE_NOTES_vX.Y.Z.md \
  --branch update

By default, only the current version’s zips are uploaded (release/*-vX.Y.Z-*.zip). Override with --assets if needed.

Publish to Qortal

• Upload the *-dist.zip to Qortal once the Gitea release is live.
• Announce using docs/USER_ANNOUNCEMENT_vX.Y.Z.md as a base.

Notes

• The release scripts avoid attaching older zip files by default.
• For re-runs where artifacts already exist, the API calls are idempotent: release is patched and assets re-uploaded as needed.