This project uses Conventional Commits to enable automatic versioning and release notes generation.
<type>(<scope>): <subject>
<body>
<footer>
- feat: A new feature (triggers minor version bump)
- fix: A bug fix (triggers patch version bump)
- docs: Documentation only changes
- style: Changes that do not affect code functionality (formatting, missing semicolons, etc.)
- refactor: Code changes that neither fix bugs nor add features
- perf: Performance improvements (triggers patch version bump)
- test: Adding or modifying tests
- build: Changes to the build system or dependencies
- ci: Changes to CI configuration files and scripts
- chore: Other changes that don't modify src or test files
- revert: Reverts a previous commit (triggers patch version bump)
Breaking changes trigger a major version bump. They can be indicated in two ways:
-
Add
BREAKING CHANGE:in the commit footer:feat: remove deprecated API endpoints BREAKING CHANGE: The /api/v1/* endpoints have been removed. Use /api/v2/* instead. -
Add
!after the type/scope:feat!: change configuration file format
feat(init): add support for Blazor templates
Added new Blazor WebAssembly and Blazor Server templates
to the project initialization options.
fix(mcp): resolve connection timeout in SSE transport
Increased default timeout from 30s to 60s to handle
slower network connections.
Fixes #123
feat(api)!: change authentication method to OAuth 2.0
BREAKING CHANGE: Basic authentication is no longer supported.
All API requests must now use OAuth 2.0 tokens.
Migration guide: https://docs.example.com/migration
docs(readme): update installation instructions
Added instructions for macOS and Windows users.
Common scopes for PKS CLI:
- init: Project initialization command
- agent: Agent management features
- mcp: Model Context Protocol integration
- deploy: Deployment features
- hooks: Git hooks integration
- prd: Product Requirements Document features
- cli: General CLI functionality
- templates: Project templates
- docs: Documentation
- tests: Test suite
- ci: CI/CD pipeline
- Keep the subject line under 50 characters
- Use the imperative mood ("add feature" not "added feature")
- Don't end the subject line with a period
- Separate subject from body with a blank line
- Use the body to explain what and why, not how
- Reference issues and PRs in the footer
- For new features: Create branches from relevant
release/*branch - For hotfixes: Create branches from
mainor create newrelease/*branch - Name branches descriptively:
feat/add-blazor-templatesorfix/connection-timeout - Ensure all tests pass before submitting PR
- Update documentation if needed
- Follow the commit message convention for all commits
- Choose target release: Create or checkout
release/X.Y.Zbranch - Create feature branch:
git checkout -b feat/amazing-feature - Develop and commit: Using conventional commit format
- Push feature branch:
git push origin feat/amazing-feature - Open PR to release branch:
feat/amazing-feature→release/X.Y.Z - Test pre-release: Use generated
vX.Y.Z-pre.Npackage - Production release: Merge
release/X.Y.Z→mainwhen ready
- Create release branch:
git checkout -b release/X.Y.Zfrom main - Create hotfix branch:
git checkout -b fix/critical-issue - Fix and commit: Using conventional commit format
- PR to release branch: Test with pre-release
- PR to main: Deploy hotfix to production
See docs/BRANCHING-STRATEGY.md for detailed workflow information.
This project uses automated semantic release:
- Commits to
maintrigger the release workflow - Commit messages are analyzed to determine version bump
- Version is automatically updated in all project files
- CHANGELOG.md is generated/updated
- GitHub release is created with release notes
- NuGet packages are published (if configured)
| Commit Type | Version Bump |
|---|---|
feat |
Minor (1.0.0 → 1.1.0) |
fix |
Patch (1.0.0 → 1.0.1) |
perf |
Patch (1.0.0 → 1.0.1) |
BREAKING CHANGE |
Major (1.0.0 → 2.0.0) |
| Others | No bump |
Feel free to open an issue if you have questions about contributing!