一键导入
release-version
// Prepare version bump PRs and releases for mod-arch-library. Use when the user asks to prepare a release, bump version, create a release PR, or publish packages.
// Prepare version bump PRs and releases for mod-arch-library. Use when the user asks to prepare a release, bump version, create a release PR, or publish packages.
| name | release-version |
| description | Prepare version bump PRs and releases for mod-arch-library. Use when the user asks to prepare a release, bump version, create a release PR, or publish packages. |
Workflow for releasing new versions of mod-arch-library packages.
The release process has two phases:
# Get the last release tag
git describe --tags --abbrev=0
# List commits since last tag
git log $(git describe --tags --abbrev=0)..HEAD --pretty=format:"- %s (#%h)" --no-merges
Group commits into:
feat:) - New functionalityfix:) - Bug fixes, style fixeschore:, docs:, refactor:) - Non-user-facing changes| Change Type | Version Bump | Example |
|---|---|---|
| Breaking changes | Major (X.0.0) | API removal, breaking interface changes |
| New features (with or without fixes) | Minor (x.Y.0) | New hooks, new components, new exports |
| Only bug/style fixes | Patch (x.x.Z) | CSS fixes, bug fixes, no new features |
# Get current version
node -p "require('./package.json').version"
DO NOT create the PR directly. Provide the following for user review:
bump-version-{NEW_VERSION}
Bump to version {NEW_VERSION}
## Description
Bump version from {OLD_VERSION} to {NEW_VERSION}
Unblocks:
- {Link to any dependent PRs in other repos, if applicable}
## Changes in this release
### Features
- {Feature description} (#{PR_NUMBER})
### Bug Fixes
- {Fix description} (#{PR_NUMBER})
### Internal
- {Internal change description} (#{PR_NUMBER})
## Merge criteria:
- [ ] The commits are squashed in a cohesive manner and have meaningful messages.
- [ ] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
- [ ] The developer has manually tested the changes and verified that the changes work
After user approves the version, update the files but DO NOT commit or push.
Provide the git commands for the user to run manually:
git checkout -b bump-version-{NEW_VERSION}
git add .
git commit -m "chore: bump version to {NEW_VERSION}"
git push -u origin bump-version-{NEW_VERSION}
Update these files:
| File | Field to Update |
|---|---|
package.json | version |
package-lock.json | version (2 places: root and packages[""]) |
mod-arch-core/package.json | version |
mod-arch-core/package-lock.json | version (2 places) |
mod-arch-shared/package.json | version |
mod-arch-shared/package-lock.json | version (2 places) |
mod-arch-kubeflow/package.json | version |
mod-arch-kubeflow/package-lock.json | version (2 places) |
mod-arch-installer/package.json | version |
All packages get the same version number (monorepo versioning).
Once the version bump PR is merged to main:
DO NOT create the release directly. Provide these instructions:
## Create GitHub Release
1. Go to: https://github.com/opendatahub-io/mod-arch-library/releases/new
2. Click "Choose a tag" → Type `{NEW_VERSION}` (e.g., `1.5.0`, no `v` prefix) → "Create new tag on publish"
3. Target: `main`
4. Release title: `v{NEW_VERSION}` (e.g., `v1.5.0`, with `v` prefix)
5. Click "Generate release notes" to auto-generate the changelog
6. Review and edit if needed
7. Click "Publish release"
This triggers the `release.yml` workflow which publishes to npm.
After release is created, verify:
release.yml workflow success| Workflow | Trigger | Action |
|---|---|---|
version-bump.yml | Manual (Actions tab) | Auto-creates version bump PR |
release.yml | GitHub Release created | Publishes to npm |
publish.yml | Manual (Actions tab) | Publish individual packages |
npm run version:patch # x.x.Z
npm run version:minor # x.Y.0
npm run version:major # X.0.0
npm run publish:all # Publish all packages
Review all open dependabot PRs in the repo, check CI status, and approve+merge those that pass. Invoke with /review-dependabot.
Review code for design token violations, SCSS convention drift, and theme wrapper compliance. Compares source files against pf-tokens-SSOT.json, MUI-default-theme-object.json, and the project's styling rules. Use when the user asks to review code, audit styling, check token usage, or review a PR for convention compliance.