QuickCorp / QuickCorp/qcobjects-new-app
Release Pipeline: migrate from version-specific branches to main/development
Nobody has claimed this yet.
- Dominant language
- CSS
- Stars
- 1
- Forks
- 4
- PR merge metrics
- No merged PRs in 30d
Description
Release Pipeline: migrate from version-specific branches to main/development
Repo: QuickCorp/qcobjects-new-app
Current state
The repo has version-specific branches (v2.4, v2.4-ts, v2.5-beta) 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.4, v2.4-ts, v2.5-beta)
- 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
developmentbranch v-patch --git --npm→ tagvX.Y.Z-beta(beta publish)- Change VERSION suffix →
v-patch --git --npm→ tagvX.Y.Z-lts(LTS publish) - PR
development→main→ merge → tagvX.Y.Zonmain(latest publish)
Branch snapshot and removal steps
git fetch --all --prune
git tag archive/v2.4 origin/v2.4
git push origin archive/v2.4
git tag archive/v2.4-ts origin/v2.4-ts
git push origin archive/v2.4-ts
git checkout -b development origin/v2.5-beta
git push -u origin development
git push origin --delete v2.5-beta v2.4 v2.4-ts
git branch -d v2.5-beta
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.4 |
origin/v2.4 |
archive/v2.4-ts |
origin/v2.4-ts |
Future considerations
- When starting a new architecture wave, branch from
maininto a feature branch, develop ondevelopment, and release via the same tag flow - Archived branches are always accessible via the archive tags
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with npmpublish-main.yml, npmpublish-beta.yml, npmpublish-lts.yml, and codeql-analysis.yml, then review the documented branch and tag flow. Consolidate the publish workflows into npmpublish.yml with the listed tag patterns and update CodeQL branch targets. Verify the archive tags, development branch, and release workflow behavior against the promotion steps.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- git, github-actions, node.js
- Domain
- ci-cd, devops, release
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 55/100