Release Pipeline: migrate from version-specific branches to main/development
Repo: QuickCorp/QCObjects-SDK
Current state
The repo has version-specific branches (v2.2, v2.3, v2.4, v2.5-beta, v2.5-ts) and three separate npm publish workflows (npmpublish-beta.yml, npmpublish-lts.yml, npmpublish-main.yml).
Why this change
Version-specific branches add complexity: CI workflows need per-branch configuration, PR paths are unclear, and promoting a beta to LTS requires manual cross-branch coordination. A single development branch with tag-based release channels simplifies everything.
What changed
- Removed all version-specific branches (v2.2, v2.3, v2.4, v2.5-beta, v2.5-ts)
- Single active development branch:
development
- Release channel is encoded in the tag suffix, not in a branch name
- Old version tracks preserved as archive tags
Branch model
main ← release digest (merged from development via PR)
development ← single active development branch
feature/* ← topic branches, PR into development
fix/*
bugfix/*
Release channels (tags)
| Tag pattern |
npm dist-tag |
Triggered by |
vX.Y.Z |
latest |
consolidated npmpublish.yml |
vX.Y.Z-lts |
lts |
consolidated npmpublish.yml |
vX.Y.Z-beta |
beta |
consolidated npmpublish.yml |
Promotion workflow
- Daily work on
development branch
v-patch --git --npm → tag vX.Y.Z-beta (beta publish)
- Change VERSION suffix →
v-patch --git --npm → tag vX.Y.Z-lts (LTS publish)
- PR
development → main → merge → tag vX.Y.Z on main (latest publish)
Branch snapshot and removal steps
git fetch --all --prune
git tag archive/v2.2 origin/v2.2 && git push origin archive/v2.2
git tag archive/v2.3 origin/v2.3 && git push origin archive/v2.3
git tag archive/v2.4 origin/v2.4 && git push origin archive/v2.4
git tag archive/v2.5-beta origin/v2.5-beta && git push origin archive/v2.5-beta
git tag archive/v2.5-ts origin/v2.5-ts && git push origin archive/v2.5-ts
git checkout -b development origin/v2.5-ts
git push -u origin development
git push origin --delete v2.5-beta v2.5-ts v2.2 v2.3 v2.4
git branch -d v2.5-ts
CI pipeline updates
| File |
Change |
npmpublish-beta.yml |
Remove — consolidated into single npmpublish.yml |
npmpublish-lts.yml |
Remove — consolidated into single npmpublish.yml |
npmpublish-main.yml |
Replace with consolidated npmpublish.yml using tag-suffix detection |
codeql-analysis.yml |
Branch targets to [main, development] |
Consolidated workflow pattern:
on:
push:
tags: ['v*']
jobs:
publish:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
registry-url: https://registry.npmjs.org
- run: npm ci
- run: npm publish
env:
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
- name: Set npm dist-tag
run: |
VER="${GITHUB_REF_NAME#v}"
case "$VER" in
*-lts) TAG=lts ;;
*-beta) TAG=beta ;;
*) TAG=latest ;;
esac
npm dist-tag add "$(node -p "require('./package.json').name")@${VER}" "$TAG"
Archived tracks
| Archive tag |
Source branch |
archive/v2.2 |
origin/v2.2 |
archive/v2.3 |
origin/v2.3 |
archive/v2.4 |
origin/v2.4 |
archive/v2.5-beta |
origin/v2.5-beta |
archive/v2.5-ts |
origin/v2.5-ts |
Future considerations
- When starting a new architecture wave, branch from
main into a feature branch, develop on development, and release via the same tag flow
- Archived branches are always accessible via the archive tags
Release Pipeline: migrate from version-specific branches to main/development
Repo: QuickCorp/QCObjects-SDK
Current state
The repo has version-specific branches (
v2.2,v2.3,v2.4,v2.5-beta,v2.5-ts) and three separate npm publish workflows (npmpublish-beta.yml,npmpublish-lts.yml,npmpublish-main.yml).Why this change
Version-specific branches add complexity: CI workflows need per-branch configuration, PR paths are unclear, and promoting a beta to LTS requires manual cross-branch coordination. A single
developmentbranch with tag-based release channels simplifies everything.What changed
developmentBranch model
Release channels (tags)
vX.Y.Zlatestnpmpublish.ymlvX.Y.Z-ltsltsnpmpublish.ymlvX.Y.Z-betabetanpmpublish.ymlPromotion workflow
developmentbranchv-patch --git --npm→ tagvX.Y.Z-beta(beta publish)v-patch --git --npm→ tagvX.Y.Z-lts(LTS publish)development→main→ merge → tagvX.Y.Zonmain(latest publish)Branch snapshot and removal steps
CI pipeline updates
npmpublish-beta.ymlnpmpublish.ymlnpmpublish-lts.ymlnpmpublish.ymlnpmpublish-main.ymlnpmpublish.ymlusing tag-suffix detectioncodeql-analysis.yml[main, development]Consolidated workflow pattern:
Archived tracks
archive/v2.2origin/v2.2archive/v2.3origin/v2.3archive/v2.4origin/v2.4archive/v2.5-betaorigin/v2.5-betaarchive/v2.5-tsorigin/v2.5-tsFuture considerations
maininto a feature branch, develop ondevelopment, and release via the same tag flow