Repository navigation
Proposal: a merge-and-auto-release workflow (merge/reject + one-click release approval) #33
Description
First, thanks for maintaining this — and for the care that clearly goes into each release. This is a suggestion to make that release work less manual for you while giving contributors cleaner attribution. I've opened an accompanying PR (#34) that implements it, so this can be as easy as a review.
The friction today
Right now, contributed PRs tend to be closed and re-applied by hand inside a bundled vX.Y.Z commit, with a kind thank-you note. That's thoughtful, but it has some costs that automation can remove:
- Attribution is lost. The bundled release commits are authored by a single account, so human contributors aren't credited in Git history or the contribution graph.
- PRs read as "Closed", not "Merged". To an outside observer (or a contributor's profile) a closed-unmerged PR looks rejected, even though the work shipped.
- Releases are manual and serial. Hand-bumping
package.json, hand-writing notes, and tagging is error-prone and bundles unrelated changes together. mainisn't branch-protected, so there's no enforced "merge is the path" guardrail.
The proposed workflow
Maintainer's only per-PR action: Merge or Reject. Releases auto-draft for one-click approval.
Before: contributor PR ──▶ owner re-applies by hand ──▶ PR closed ──▶ manual bump+tag ──▶ publish
After: contributor PR ──▶ owner clicks Merge ──▶ draft Release auto-updates ──▶ owner clicks Publish ──▶ publish
- A contributor opens a PR; you apply a version label when merging (unlabeled defaults to a patch).
- You merge it (squash is fine) — that's the whole per-PR interaction. Attribution and "merged" status are preserved automatically.
- A draft GitHub Release is kept continuously up to date with categorised notes and the next semver version.
- When you want to ship, you review that draft and click Publish — the single approval gesture. That tags the release and the existing publish workflow does the Marketplace + Open VSX +
.vsixsteps.
Two ways to implement it (both give you merge/reject + approval)
| A. Release Drafter (recommended) | B. release-please | |
|---|---|---|
| Per-PR action | Merge (+ pick a version label; defaults to patch) | Merge with a conventional-commit title |
| What auto-builds | A draft GitHub Release (notes + next version from PR labels) | An open "chore: release X.Y.Z" PR that bumps package.json + CHANGELOG.md |
| Approval gesture | Open the draft, click Publish | Merge the release PR |
package.json / changelog sync |
small step in the publish workflow stamps the version from the tag | auto-handled by the bot |
| Process cost | just PR labels | requires conventional-commit titles |
Recommendation: Option A (Release Drafter) — it's the lightest change on top of the existing tag-based publish.yml and matches a "draft release you approve" mental model. Option B is cleaner for package.json/changelog sync but asks everyone to adopt conventional-commit titles.
The PR
#34 implements Option A (Release Drafter) end-to-end — the two workflow files, the config, and the doc updates. It's ready to merge as-is; I'm equally happy to rework it as Option B (release-please) if that fits your preferences better.
The zero-tooling first step
Even before any of this: switching from close-and-reapply to simply squash-merging contributor PRs immediately restores attribution and the "merged" status, at no cost. The automation above is just the next layer on top.
I know workflow changes are personal to how you like to run the project — so treat the PR as a starting point, and tell me what you'd change. Happy to adjust.
Activity
ildyria commentedon Jun 14, 2026
Hi, I support this change.
Note that even without changing the release workflow, the main branch should be protected.
The author could just do:
and the process still works.
But the switch to protected branch + merge flow (squash) is mandatory IMHO.
Carl723000 commentedon Jun 15, 2026
Thanks @nickearnshaw for the proposal + PR, and @ildyria for jumping in.
As a first-time maintainer I defaulted to close-and-reapply to keep a tight grip on quality, and I hadn't fully weighed the attribution cost that puts on contributors. I'm switching to the merge-based flow.
Plan for these days:
main(require a PR before merge) — agreed it's mandatory regardless of the release tooling..github/CODEOWNERS(@Carl723000 @jack21) per @ildyria's suggestion.@jack21 — flagging this since the cleanup adds merge commits to
main's history.I'll work through #32 → #34 → #35 and the open PRs this week. Really appreciate the care you've all put in.
ci: pin workflow actions to commit SHAs + add CODEOWNERS (#32/#33)