chore(release): 🔧 update release workflow for versioning and prerelease#23
Conversation
- rename version_type to release_type with new description - add prerelease options for alpha, beta, and rc - adjust version bump logic to handle prerelease identifiers
There was a problem hiding this comment.
Pull request overview
This PR updates the release automation to support prerelease variants (alpha/beta/rc) and adjusts the versioning script and GitHub Actions workflow to propagate the computed version/tag through the pipeline.
Changes:
- Extend
version-manager.tsto accept a--prerelease-id(alpha/beta/rc) and pass it into prerelease bump logic. - Update
release.ymlworkflow inputs (version_type→release_type) and derive the npm dist-tag from the resulting version. - Expose bumped version/tag/prerelease status as job outputs and use them during publish and GitHub Release creation.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
scripts/version/version-manager.ts |
Adds prerelease identifier support and wires it into version bumping/CLI parsing. |
.github/workflows/release.yml |
Updates manual dispatch inputs and release steps to bump versions for alpha/beta/rc and publish with derived npm tags. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| components.prerelease.version++; | ||
| } | ||
| } else { | ||
| // Add new prerelease |
There was a problem hiding this comment.
In the prerelease bump path, when the current version is stable (no existing components.prerelease), the code only adds a prerelease suffix without incrementing the patch version. That yields 1.0.0 -> 1.0.0-alpha.0, which contradicts the help text in this file (and typical SemVer flow) that expects 1.0.0 -> 1.0.1-alpha.0. Consider incrementing components.patch before setting components.prerelease when starting a new prerelease from a stable version.
| // Add new prerelease | |
| // Start a prerelease for the next patch version | |
| components.patch++; |
| ;; | ||
| auto) | ||
| pnpm version:auto | ||
| ;; |
There was a problem hiding this comment.
This case statement has no default (*) branch. If inputs.release_type is ever an unexpected value (e.g., future option added, or a manual workflow_dispatch payload), the bump will be skipped silently and the workflow will proceed using the old version. Add a default branch that prints an error and exits non-zero before esac.
| ;; | |
| ;; | |
| *) | |
| echo "❌ Unsupported release_type: $RELEASE_TYPE" >&2 | |
| exit 1 | |
| ;; |
| release_type: | ||
| description: "Release type (alpha/beta/rc are prerelease variants)" | ||
| required: true |
There was a problem hiding this comment.
The workflow inputs were renamed/repurposed (version_type → release_type, and prerelease options changed), but .github/workflows/README.md still documents the old version_type input. To avoid confusing maintainers, update the workflow documentation to match the new inputs and options.
| case '--prerelease-id': { | ||
| const id = args[++i]; | ||
| if (id !== 'alpha' && id !== 'beta' && id !== 'rc') { | ||
| console.error(`Invalid prerelease id: ${id} (expected alpha, beta, or rc)`); | ||
| process.exit(1); |
There was a problem hiding this comment.
--prerelease-id is accepted regardless of the chosen versionType. If a caller passes --prerelease-id with patch/minor/major (or with --auto resulting in non-prerelease), it will be silently ignored. Consider validating that --prerelease-id is only allowed when the resolved version type is prerelease (or failing fast when incompatible) to prevent confusing CLI usage.
✅ PR Validation Passed
📋 Pipeline Status
📊 Code Coverage
🧬 Mutation Testing
ℹ️ About this report
🤖 Generated by @helpers4 CI • 2026-04-04 |
Description
Please include a summary of what this PR does and why it's needed.
Type of Change
Related Issues
Closes #(issue number)
How Has This Been Tested?
Describe the tests you ran and how to reproduce them:
Checklist
Screenshots (if applicable)
Add screenshots for UI changes.
Additional Context
Add any other context about the PR here.