-
Notifications
You must be signed in to change notification settings - Fork 0
Release workflow
Step-by-step checklist for deploying an amendment release, from initial proposal through to the published bylaws on the website.
- Push access to the repository
- Node.js installed, with
npm installcompleted in the repo root - Git configured for commits and tagging
- Membership in
@CatholicOS/board(required for BYLAWS.md approval)
-
Create an amendment branch from
main:git checkout main && git pull git checkout -b amendment/YYYY-NN-short-titleThe branch name must match the pattern
amendment/YYYY-NN-short-title(e.g.amendment/2026-02-quorum-threshold). CI will reject any other pattern whenBYLAWS.mdis modified. -
Edit
BYLAWS.mdwith the proposed changes.- Do not update the
Version:orLast Amended:fields — the merge script sets these automatically from the tag. - Optionally update
CHANGELOG.md.
- Do not update the
-
Do not modify any other files in the amendment branch. CI enforces that only
BYLAWS.mdandCHANGELOG.mdare changed. -
Commit and push the branch:
git add BYLAWS.md git commit -m "Amendment YYYY-NN: short description" git push -u origin amendment/YYYY-NN-short-title
-
Open a Pull Request against
main. The PR template will load automatically — fill in every section:- Amendment ID and proposed version increment
- Summary of changes (articles/sections affected)
- Rationale
- Approval authority (Board resolution, members' vote, etc.)
-
CI checks run automatically on the PR:
-
Markdown Lint — validates formatting of all
.mdfiles. - Governance Enforcement — verifies the amendment branch name.
-
Bylaws Approval Check — requires at least 3 approvals from
@CatholicOS/boardmembers before the PR can merge.
-
Markdown Lint — validates formatting of all
-
Obtain formal approval outside of GitHub (Board resolution, members' vote, etc.) as required by the bylaws. Record the resolution number or date in the PR's "Approval record" section.
-
Collect the required reviews on the PR (minimum 3 approvals).
-
Merge and tag using the npm helper:
npm run merge -- <PR_NUMBER> <TAG>
For example:
npm run merge -- 7 v1.1
This command automates the entire merge-and-tag flow:
- Checks out the PR branch and updates
BYLAWS.md— setsLast Amended:to today andVersion:to match the tag - Pushes the update commit to the PR branch
- Waits for CI checks to pass
- Merges the PR into
mainusing a merge commit (no squash/rebase) - Updates local
mainand deletes the amendment branch - Creates an annotated tag and pushes it to origin
If you want to merge without tagging (e.g. to tag later), omit the tag:
npm run merge -- 7
- Checks out the PR branch and updates
-
CI validates the tag automatically:
- Tag name matches
vMAJOR.MINORformat - Tag name matches the
Version:declared inBYLAWS.md -
Last Amended:date matches the tagged commit's date
- Tag name matches
-
Deployment triggers automatically — once governance enforcement passes on the tag push, the Deploy Bylaws to WordPress workflow:
- Converts
BYLAWS.mdto HTML via Pandoc - Publishes or updates the bylaws page on the WordPress site
- Converts
[ ] Branch created: amendment/YYYY-NN-short-title
[ ] BYLAWS.md edited with version incremented
[ ] PR opened using the amendment template
[ ] CI checks passing (lint, branch name, approval count)
[ ] Formal approval obtained and recorded in PR
[ ] 3+ board approvals on the PR
[ ] npm run merge -- <PR> vX.Y executed
[ ] CI tag validation passing
[ ] WordPress deployment confirmed
The tag was created without using npm run merge or npm run tag, so the
date in BYLAWS.md is stale. Delete the tag, run npm run tag -- vX.Y on
main, and push again:
git tag -d vX.Y
git push origin :refs/tags/vX.Y
npm run tag -- vX.Y
git push origin vX.YThe Version: field in BYLAWS.md was not incremented to match the tag.
Go back and amend the version in a new commit before tagging.
The PR may have already been merged or closed. Check its state with
gh pr view <PR_NUMBER>.
The PR needs at least 3 approvals from @CatholicOS/board members.
Request additional reviews before merging.