cut-release

# Cut a meshkit release Publishing a release here is intentionally a one-action step: **flip the existing Release Drafter draft from draft to published.** meshkit is a Go module consumed by tag, so publishing the draft cuts the version tag that downstream repos (meshery, meshery-cloud, and the other ecosystem components) then bump their `go.mod` to. ## How releasing works in this repo - `.github/workflows/release-drafter.yml` runs on **every push to `master`**. As PRs merge, it maintains a single **draft** GitHub Release whose tag auto-increments (the patch version bumps after each publish). There is always exactly one draft waiting to be published. - Publishing that draft (the release `published` event) creates the immutable version **tag** and finalizes the notes. meshkit has **no build/deploy workflow that fires on the release event** - it is a Go library, so the release *is* the tag. Consumers pick up the new version by running `go get github.com/meshery/meshkit@<tag>` (or a dependency bump PR) in their own repos. So the tag is already chosen and the notes are already drafted. Your job is only to make sure the just-merged PR is reflected in the draft, then publish it. **Do not create a tag, do not bump a version, do not write release notes by hand** - Release Drafter owns all of that. ## Steps ### 1. Confirm the Release Drafter run for the latest master commit has finished The draft only includes a PR after the drafter workflow run for that merge commit completes. If you publish too early, the just-merged PR is missing from the notes. ```bash # Latest master commit that should be in the release git fetch origin master --quiet && git rev-parse origin/master # Most recent Release Drafter runs (headSha should match origin/master, status "completed") gh run list --workflow="release-drafter.yml" --branch master --limit 3 \ --json databaseId,status,conclusion,headSha,createdAt ``` If the run for the current `origin/master` SHA is still `in_progress` (or absent because the push just landed), wait for it before publishing: ```bash gh run watch <databaseId> --exit-status ``` A `conclusion` of `success` for the run whose `headSha` matches `origin/master` means the draft is up to date. If the latest run **failed**, stop and surface that - do not publish stale notes. ### 2. Identify and inspect the draft ```bash # Tag of the current draft (there is normally exactly one) gh release list --limit 25 --json tagName,isDraft --jq '.[] | select(.isDraft) | .tagName' # Read the draft notes and confirm the recently merged PR appears in them gh release view <draftTag> --json tagName,name,isDraft,body --jq \ '{tag: .tagName, name: .name, isDraft: .isDraft, body: .body}' ``` Verify the merged PR the user is releasing shows up under one of the category headings. If it does not, the drafter run from step 1 has not yet indexed it - re-check step 1 rather than publishing without it. If more than one draft is ever returned, stop and ask the user which to publish rather than guessing - publishing the wrong one ships an unintended version. ### 3. Publish the draft Flipping `--draft=false` publishes it, which cuts the version tag. Mark it `--latest` so it carries the "Latest" badge. ```bash gh release edit <draftTag> --draft=false --latest ``` ### 4. Confirm it published ```bash gh release view <draftTag> --json tagName,isDraft,isLatest,publishedAt --jq \ '{tag: .tagName, isDraft: .isDraft, isLatest: .isLatest, publishedAt: .publishedAt}' ``` `isDraft: false` and a non-null `publishedAt` confirm the release is out. Report the published version to the user and note that downstream consumers can now bump to `@<tag>`. ## What to watch for - **Don't publish ahead of the drafter run.** The most common failure is publishing before the Release Drafter workflow has folded the merged PR into the notes, shipping a release whose notes omit the very change being released. Step 1 exists to prevent exactly this. - **Never hand-author the tag or notes.** If you find yourself computing a version number or writing changelog entries, something is wrong - Release Drafter already did both. - **One draft only.** If `gh release list` shows zero drafts, no drafter run has occurred since the last release; if it shows more than one, ask the user which to publish.