# 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.