mirror of
https://github.com/github/awesome-copilot.git
synced 2026-04-30 20:25:55 +00:00
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.
93 lines
2.9 KiB
Markdown
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 |
|