45844de534
Consolidate the repository into clearer apps, tools, and layered docs areas so contributors can navigate and maintain it more reliably. Align validation, metadata sync, and CI around the same canonical workflow to reduce drift across local checks and GitHub Actions.
1.8 KiB
1.8 KiB
Release Process
This is the maintainer playbook for cutting a repository release. Historical release notes belong in CHANGELOG.md; this file documents the repeatable process.
Preconditions
- The working tree is clean, or you have explicitly isolated the release changes.
package.jsoncontains the version you intend to publish.- Generated registry files are synchronized.
- README counts, badges, and acknowledgements are up to date.
Release Checklist
- Run the operational verification suite:
npm run validate
npm run validate:references
npm run sync:all
npm run test
npm run app:build
- Optional hardening pass:
npm run validate:strict
Use this as a diagnostic signal. It is useful for spotting legacy quality debt, but it is not yet the release blocker for the whole repository.
- Update release-facing docs:
- Add the release entry to
CHANGELOG.md. - Confirm
README.mdreflects the current version and generated counts. - Confirm Credits & Sources, contributors, and support links are still correct.
- Create the release commit and tag:
git add README.md CHANGELOG.md CATALOG.md data/ skills_index.json package.json package-lock.json
git commit -m "chore: release vX.Y.Z"
git tag vX.Y.Z
- Publish the GitHub release:
gh release create vX.Y.Z --title "vX.Y.Z" --notes-file CHANGELOG.md
- Publish to npm if needed:
npm publish
Rollback Notes
- If the release tag is wrong, delete the tag locally and remotely before republishing.
- If generated files drift after tagging, cut a follow-up patch release instead of mutating a published tag.
- If npm publish fails after tagging, fix the issue, bump the version, and publish a new release instead of reusing the same version.