release-tasks

name	release-tasks
description	Prepare a new release: bump the version, verify the Docker build, create a release branch, run all tests (backend, frontend, E2E), and update the changelog, README, and in-app documentation. Run this skill before release-publish.

Release Tasks

Complete these steps in order to prepare a release. When everything here is done, run the release-publish skill to merge and tag.

1. Bump the Version

Update the version number in the project's configuration files. Version numbers follow semantic versioning (major.minor.patch, e.g., 1.0.0). Increment the appropriate part based on the changes since the last release.

2. Update and Check the Docker Build

Review the docker-compose files used to set up the development environment and verify that they work correctly.

3. Create a Release Branch

Create a release branch from the main development branch (e.g., main). Name it after the version being released (e.g., release-1.0.0). Use this branch for all remaining steps.

4. Run Backend and Frontend Tests

Run the full unit and integration test suites:

make test-backend   # pytest
make test-frontend  # Vitest

Fix any failures before proceeding.

5. Run E2E Tests

Run the end-to-end (E2E) tests to verify that the software works correctly end-to-end. Fix any issues that arise.

make test-e2e

6. Update the Changelog

Update CHANGELOG.md with all notable changes since the last release. List them in chronological order under the new version number.

7. Update README.md

If the project's functionality or usage has changed, update README.md to reflect those changes.

8. Update the Documentation (in-app, GitHub Pages, language coverage)

This must be checked on every release — stale docs ship silently.

If the project's functionality or usage has changed:

• In-app docs (frontend/src/docs/content/{en,de,fr,es}.ts): update every affected language for each shipped feature. Docs content is EN/DE/FR/ES only (there is no zh docs file — Chinese UI falls back to English docs).
• GitHub Pages (docs/ → published site): mirror the same updates so the public docs site matches the in-app docs.
• Language coverage: if a UI locale was added/removed, update the language list in tour.langSwitcher.description (ALL frontend/src/i18n/locales/*.ts) and the "Language Support" table in the docs. The number stated in the prose must equal the number of shipped locales.

What's auto-verified vs. manual:

• Auto (Gate 8 — i18n & docs consistency, phase4-gates.yml): every UI locale is structurally complete (en/de/fr/es/zh), the tour's stated language count matches the real locale count, and all four doc locales share the same top-level section ids. Specs: frontend/src/tests/i18n/{locale-parity,ZhLocaleParity,language-and-docs-consistency}.spec.ts.
• Manual (this step): that the doc prose actually describes the new features — a gate can't read intent. Walk each shipped feature and confirm it's documented in all four languages + GitHub Pages before tagging.

9. Build and Test Distribution ZIPs

Build the standalone offline distribution archives for all platforms and verify they work:

# Build for Linux/macOS (can run on any Unix host)
bash scripts/build-mac-and-linux.sh linux
bash scripts/build-mac-and-linux.sh macos-arm64
bash scripts/build-mac-and-linux.sh macos-x86_64

# Build for Windows (must run on a Windows host or via CI)
# Option A: On a Windows machine:
#   powershell -ExecutionPolicy Bypass -File scripts/build-windows.ps1
# Option B: CI builds it automatically on windows-latest (build.yml workflow)

# Also build the online (lightweight) variant
bash scripts/build-online-mac-and-linux.sh

Verify:

• All ZIPs are created under dist/
• Spot-check at least one ZIP: extract it, confirm it contains frontend_dist/, backend/, install/start scripts, and wheels
• Ensure the version in the built artifacts matches the release version