|
| 1 | +--- |
| 2 | +description: Walk through the release checklist interactively |
| 3 | +allowed-tools: Read, Grep, Bash(git fetch *), Bash(git checkout *), Bash(git switch *), Bash(git pull *), Bash(git add *), Bash(git commit *), Bash(git push *), Bash(git status*), Bash(git branch *), Bash(gh issue view *), Bash(pwsh -Command ./src/scripts/*), Bash(pwsh -Command "./src/scripts/*) |
| 4 | +--- |
| 5 | + |
| 6 | +# Release |
| 7 | + |
| 8 | +## Phase 1: Setup |
| 9 | + |
| 10 | +Fetch origin and create a release prep branch from `origin/dev` (e.g., `{username}/v14`). If the branch already exists locally, switch to it and pull. |
| 11 | + |
| 12 | +```bash |
| 13 | +pwsh -Command "./src/scripts/Start-Release.ps1 -OutputFile (Join-Path ([System.IO.Path]::GetTempPath()) 'ftk-release.json')" |
| 14 | +``` |
| 15 | + |
| 16 | +Read the JSON file from the temp path printed in the output. Report the release issue URL and milestone summary to the user. |
| 17 | + |
| 18 | +## Phase 2: Core features |
| 19 | + |
| 20 | +Do the following in parallel: |
| 21 | + |
| 22 | +1. **Launch background build/test commands.** Use Bash with `run_in_background` for each: |
| 23 | + |
| 24 | + - `pwsh -Command ./src/scripts/Build-Toolkit.ps1` |
| 25 | + - `pwsh -Command "./src/scripts/Test-PowerShell.ps1 -Unit"` |
| 26 | + - `pwsh -Command "./src/scripts/Test-PowerShell.ps1 -Lint"` |
| 27 | + - `pwsh -Command "./src/scripts/Test-PowerShell.ps1 -Integration"` |
| 28 | + |
| 29 | +2. **Triage milestone items** using the layered approach below. |
| 30 | + |
| 31 | +### Milestone triage |
| 32 | + |
| 33 | +Analyze all milestone items and recommend keep vs push for each. The release is expected within ~7 days, so push anything complex unless it's a bug fix or a feature explicitly targeting this release. Use labels, titles, and summaries to judge — don't over-explain your reasoning in questions. |
| 34 | + |
| 35 | +Group items by topic, then present via AskUserQuestion. Use the version tag from the JSON (e.g., "v14") and the next milestone title (e.g., "v15") in option labels. |
| 36 | + |
| 37 | +**Round 1: Bulk triage by group** (up to 4 groups per AskUserQuestion call). |
| 38 | + |
| 39 | +- **Header:** 1-3 word group name |
| 40 | +- **Question:** Plain text, no formatting. "{count} items: #{number} {short title}, #{number} {short title}, ..." Titles 3-5 words each. |
| 41 | +- **Options:** Recommendation first with "(Recommended)". Always include: "Keep all", "Push all", "Review individually". |
| 42 | + |
| 43 | +**Round 2: Individual review** (only for groups where user chose "Review individually"). |
| 44 | + |
| 45 | +- **Header:** "#{number}: {1-3 word title}" |
| 46 | +- **Question:** Plain text summary from JSON data, up to 100 words. State your recommendation and why. |
| 47 | +- **Options:** "Keep in {version} (Recommended)" or "Push to {next version} (Recommended)" (whichever you recommend first), the other option, and "Investigate further". |
| 48 | +- If "Investigate further" is chosen, fetch details via `gh issue view {number}`, provide deeper analysis, and re-present. |
| 49 | + |
| 50 | +**After triage:** Report which items are staying and which are being pushed. Do NOT move milestones — just report for the user to act on. |
| 51 | + |
| 52 | +### Untriaged issues |
| 53 | + |
| 54 | +If `NeedsReview` in the JSON contains any issues, present them for quick triage using the same Round 1/Round 2 pattern. These are issues with the "Needs: Review 👀" label that haven't been triaged yet. |
| 55 | + |
| 56 | +### Build/test results |
| 57 | + |
| 58 | +After triage, check on the background agents. If all passed, report a brief summary. For each failure, show the error output and present via AskUserQuestion with options: "Investigate and fix", "Skip for now". |
| 59 | + |
| 60 | +### Changelog review |
| 61 | + |
| 62 | +Read @docs-mslearn/toolkit/changelog.md and review the current version section against the changelog standard in @docs-wiki/Coding-guidelines.md. Apply fixes directly — no AUQ needed. Specific checks: |
| 63 | + |
| 64 | +- Only one version section for this release (no duplicates). |
| 65 | +- Unreleased section should be empty (we release from dev). Flag any content there. |
| 66 | +- Tool sections match the order from the previous release. Flag any new tools or reordering. |
| 67 | +- Categories in order: Added, Changed, Fixed, Deprecated, Removed. Empty categories omitted. |
| 68 | +- Every entry starts with a past-tense verb, ends with a period, follows content guidelines. |
| 69 | +- Entries are concise. Trim verbose or implementation-detail-heavy text. |
| 70 | +- Issue links present where applicable, formatted as `([#{number}](url))`. |
| 71 | +- Breaking changes prefixed with `**Breaking:**` and listed first in their category. |
| 72 | +- No filler entries ("various bug fixes", "minor improvements"). |
| 73 | +- Entries placed in the correct category (e.g., new things under Added, not Changed). |
| 74 | + |
| 75 | +After applying fixes, show a summary of what was changed so the user can review. |
| 76 | + |
| 77 | +### What's new blurbs |
| 78 | + |
| 79 | +Find all `<div id="whats-new">` blocks in `/docs/`. For each: if the tool has a section in the changelog, uncomment the block (if needed) and update the month, year, version tag, and paragraph with a 1-2 sentence summary. If the tool has no changelog section, comment out the block. |
| 80 | + |
| 81 | +Show a summary of all changelog and what's new changes for the user to review, then ask via AskUserQuestion whether to commit and push to the prep branch. |
| 82 | + |
| 83 | +### Next actions |
| 84 | + |
| 85 | +After all triage and build/test results are reported, analyze the kept milestone items and suggest concrete next actions: |
| 86 | + |
| 87 | +- PRs from others awaiting the user's review |
| 88 | +- The user's PRs that have reviewer feedback to address |
| 89 | +- Issues with no open PRs and no one actively working them |
| 90 | + |
| 91 | +Present as a prioritized list — no AUQ needed, just a summary the user can act on. |
0 commit comments