release

# Release Actions Follow these steps in order when doing a release. Ask the user for the **new version number** and **changelog content** (list of PRs/changes from GitHub) before starting if they haven't been provided. --- ## Step 0 — Collect inputs Ask the user (if not already provided): 1. **New version number** (e.g. `2.1.0`) 2. **Previous version number** (e.g. `2.0.0`) — used for the GitHub compare URL 3. **Release date** in `YYYY-MM-DD` format (default: today) 4. **Raw changelog** — the GitHub "What's Changed" PR list for this release --- ## Step 1 — Update version numbers Files to update: | File | What to change | |---|---| | `robotframework_dashboard/version.py` | `__version__ = "Robotdashboard X.Y.Z"` | | `setup.py` | `version="X.Y.Z"` | Both must use the exact same new version number. --- ## Step 2 — Update the CLI test expected output File: `tests/robot/resources/__snapshots__/00_cli/version.txt` The last line of this file is the version string that the robot test compares against the CLI `--version` output (a `SnapshotLibrary` snapshot). Update it to: ``` Robotdashboard X.Y.Z ``` Do not change the ASCII art banner lines above it. --- ## Step 3 — Regenerate the example dashboard and database The example dashboard and database live in `example/robot_dashboard.html` and `example/robot_results.db`. They are what every *released* docs version serves; the `/dev/` docs rebuild the example from `main` on every deploy (`scripts/docs/build-versioned-docs.mjs`), so this step is only about the release itself. Run from anywhere (any OS): ```bash python scripts/example.py # or scripts\example.bat from cmd.exe ``` `scripts/example.py` deletes `robot_results.db` / `robot_dashboard.html` in the repo root, imports the fixtures from `tests/robot/resources/outputs/` with tags, versions, timezones, custom filters and the message config, then copies the results to `example/`. `scripts/example.bat` is a one-line wrapper around it (path-independent, forwards arguments). The fixtures themselves are generated by `tests/robot/resources/generator/generate.py` (see its README); they only need regenerating when the generator changes, not per release. --- ## Step 4 — Update CHANGELOG.md Insert a new section **at the top** of the changelog (after the header block, before the previous latest version). Match the existing style exactly. **Template:** ```markdown ## [X.Y.Z](https://github.com/MarketSquare/robotframework-dashboard/releases/tag/vX.Y.Z) - YYYY-MM-DD ### Added - <feature description> ### Fixed - <fix description> ### Changed - <change description> --- ``` Rules: - Only include `### Added`, `### Fixed`, `### Changed` sections that are non-empty. - Write human-readable bullet points — do not paste the raw PR titles verbatim. Rewrite them as clear, user-facing descriptions. - Omit contributor attribution and PR URLs (those belong on GitHub Releases, not the changelog). - Use backticks for CLI flags, file names, and code references. --- ## Step 5 — Generate Slack release notes Produce a ready-to-paste Slack message. Keep it **short and scannable**: the notes announce the release, the changelog and docs hold the detail. Rules: - **One-line summary** under the title, naming the theme of the release (e.g. "A small performance release: …"). - **Section headers without emoji**: `Added`, `Fixed`, `Changed`, `Resources`, in that order, only the non-empty ones. No `---` separators. - **One bullet per change**: `*<Short name>* — <one or two sentences on what changed and why it matters to the user>`. No code examples, no per-bullet docs links, no PR numbers. - **No timings in the bullets.** When a release is about performance, put the headline gains in the summary line or a single closing bullet as percentages or "N× faster" measured on a large dashboard, and state the dataset size once (e.g. "on a dashboard with 504 runs and 208k test results"). Never list raw millisecond numbers. - **Fixed bullets** are plain sentences describing the user-visible symptom that is gone. - **Thank external contributors inline**: scan the PR authors and co-authors for anyone who is *not* `@timdegroot1996` and end the bullet their work landed in with `Thanks @name for …!` (no emoji). - **Resources** always has the same four lines. Format: ``` :robot: *Robot Framework Dashboard vX.Y.Z is out!* :tada: <one-line summary of the release theme> *Added* • *<Feature name>* — <one or two sentences>. *Changed* • *<Change name>* — <one or two sentences>. Thanks @contributor for <what they did>! *Fixed* • <what the user no longer runs into>. *Resources* Full changelog: https://github.com/MarketSquare/robotframework-dashboard/compare/vPREVIOUS...vX.Y.Z PyPI: https://pypi.org/project/robotframework-dashboard/X.Y.Z/ Docs: https://marketsquare.github.io/robotframework-dashboard/ Example dashboard: https://marketsquare.github.io/robotframework-dashboard/example/robot_dashboard.html ``` --- ## Step 6 — Update CLAUDE.md (optional) If a **new skill** was created under `.claude/skills/` as part of this release, add it to the skills table in `CLAUDE.md`. --- ## Step 7 — After the release PR is merged: tag, GitHub Release, docs The user merges the release PR (squash, `Release X.Y.Z (#PR)`), uploads to PyPI and posts the Slack notes. The rest, in this order: 1. **Tag the merge commit** — never before the merge, or the tag points at a commit that is not on `main`: ```bash git checkout main && git pull git tag vX.Y.Z && git push origin vX.Y.Z ``` 2. **GitHub Release** — same style as the earlier releases (auto-generated "What's Changed"): ```bash gh release create vX.Y.Z --title "Robotdashboard vX.Y.Z" --generate-notes --notes-start-tag vPREVIOUS --latest ``` Check `gh release list` first: every tag should have a release, so create any missing earlier one (oldest first) before this one so `--latest` ends up on the new version. 3. **Re-run the docs deploy.** `.github/workflows/deploy.yml` runs only on pushes to `main` (plus `workflow_dispatch`), **not** on tags; it builds every release tag it finds (`scripts/docs/build-versioned-docs.mjs`). The run started by the merge usually builds before the tag exists, so trigger it again after the tag push: ```bash gh workflow run deploy.yml ``` Once that run is green, check: - `https://marketsquare.github.io/robotframework-dashboard/` shows `vX.Y.Z` in the nav bar (the root is always the latest tag) - `https://marketsquare.github.io/robotframework-dashboard/vX.Y.Z/` exists - `https://marketsquare.github.io/robotframework-dashboard/versions.json` lists the new version with `"latest": true` --- ## Quick checklist - [ ] `robotframework_dashboard/version.py` — version updated - [ ] `setup.py` — version updated - [ ] `tests/robot/resources/__snapshots__/00_cli/version.txt` — version string updated - [ ] `example/robot_dashboard.html` — regenerated - [ ] `example/robot_results.db` — regenerated - [ ] `CHANGELOG.md` — new section added at the top - [ ] Slack release notes produced (short format, no timings, contributors thanked inline) - [ ] After the merge: `vX.Y.Z` tag pushed on the merge commit, GitHub Release created - [ ] `gh workflow run deploy.yml` after the tag push; `/`, `/vX.Y.Z/` and `versions.json` on the docs site show the new version