TUIkit releases should be tagged, changelogged, documented, and validated before publication.
- Pre-1.0 feature releases use
0.x.0. - Pre-1.0 patch releases use
0.x.y. - Release candidates use a prerelease suffix such as
0.7.0-rc.1. - Do not tag an RC until automated validation passes and manual terminal-validation gaps are explicitly accepted or completed.
swift build
swift test --parallel
swiftlint
swift package --allow-writing-to-directory docc-output \
generate-documentation \
--target TUIkit \
--output-path docc-output \
--transform-for-static-hosting
./scripts/release-validation-checklist.shRun ./scripts/test-linux.sh when Docker/Linux validation is available.
Use docs/ReleaseValidationChecklist.md and record only actually-tested terminal results in docs/TerminalCompatibility.md.
Before tagging:
- Move
CHANGELOG.mdentries fromUnreleasedinto a versioned section. - Include migration notes for breaking changes.
- Include known limitations and terminal compatibility status.
- Confirm README installation examples use a tag appropriate for the release line.
- Generate DocC and keep docs clearly associated with the release tag or labeled as main-branch docs.
After validation and maintainer approval:
git tag -a <version> -m "TUIkit <version>"
git push origin <version>Do not tag from a dirty working tree.