Files
awesome-copilot/skills/github-release/references/semver-rules.md
Adriano Nogueira 278b1ebf56 Add github-release skill and references (#1562)
Introduce a new github-release skill: adds skills/github-release/SKILL.md with a 9-step GitHub release workflow (gh/git-based, SemVer, Keep a Changelog guidance). Also adds reference heuristics for commit classification and SemVer decision rules, and updates docs/README.skills.md to list the new skill.
2026-04-30 10:25:04 +10:00

93 lines
2.9 KiB
Markdown

# SemVer Decision Rules
Reference: https://semver.org/
---
## Version format
```
vMAJOR.MINOR.PATCH
```
- **MAJOR** — incompatible API changes
- **MINOR** — new backward-compatible functionality
- **PATCH** — backward-compatible bug fixes
Pre-1.0 note: if the current version is `0.x.y`, anything goes — MINOR bumps are
common for breaking changes. Once past `1.0.0`, the rules below apply strictly.
---
## What counts as a MAJOR bump (breaking change)
Breaking changes are any modifications that could cause a consumer of the library to
experience a compile error, runtime error, or behavior change **without changing their
own code**.
Examples:
- Removing a public function, class, method, or constant
- Renaming a public function, class, method, or constant
- Changing a function signature (adding required parameters, removing parameters,
changing parameter types, changing return type)
- Changing observable behavior that callers depend on (e.g., error types thrown,
event names emitted, return value shape)
- Changing a required configuration key or its accepted values
- Dropping support for a runtime/language version that was previously supported
- Removing or renaming a publicly exported module path
**When in doubt, prefer a MAJOR bump over a MINOR.** It's better to signal a breaking
change than to silently break consumers.
---
## What counts as a MINOR bump (new feature)
- Adding a new public function, class, method, or constant
- Adding optional parameters to an existing function (with backward-compatible defaults)
- Implementing a new protocol/interface that doesn't affect existing ones
- Adding new configuration keys with sensible defaults
- Deprecating (but not removing) a public API — removal comes in a future MAJOR
---
## What counts as a PATCH bump
- Fixing a bug where behavior was incorrect relative to documented intent
- Improving performance without changing the public API
- Internal refactoring with no external observable difference
- Documentation updates
- Dependency updates that don't change the library's own public surface
- CI/CD, test, tooling changes
- Security fixes that don't break the API
---
## Multiple changes — precedence
When a release contains a mix of change types, the **highest precedence** wins:
```
MAJOR > MINOR > PATCH
```
One breaking change + ten new features = MAJOR bump.
---
## First release (no prior tags)
Default to `1.0.0` regardless of what's in the diff. Inform the user.
---
## Edge cases
| Situation | Recommendation |
|---|---|
| Only internal/private symbols changed | PATCH |
| Type annotation added to previously untyped function | PATCH (non-breaking) |
| Changing default value of optional parameter | Treat as MAJOR if callers might rely on old default |
| Adding a new required config option to an optional block | MINOR if the block itself is optional, otherwise MAJOR |
| Reverting a previous commit entirely | Follow what the net diff shows, not the revert message |