Versioning Policy
Versioning model
- major: breaking public API/CLI/generator/migration changes
- minor: additive and compatible features
- patch: backward-compatible fixes
- the shipped CLI banner/version tracks the published package version
- CLI-only changes follow the same SemVer rules based on user-facing impact
Breaking changes
When breaking:- update changelog
- include upgrade note
- provide migration path when feasible
Package rename and scope migration
- renaming the package or changing its npm scope is always
major - treat package identity changes as consumer migrations, not registry-only maintenance
- review install command changes, import path changes, generated-code impact, docs/example updates, and dependency migration guidance before approving a rename
- do not rename the package only to satisfy GitHub Packages publishing; prefer npmjs as canonical, or move the repo under a matching GitHub owner/org if GitHub Packages is required
Minor changes
- new commands
- new APIs
- new options
- new drivers/features without contract changes
- new backward-compatible CLI flags or additive CLI features
Patch changes
- bug fixes
- security fixes
- docs corrections
- internal refactors without public contract drift
- backward-compatible CLI fixes, including banner/version reporting corrections
Deprecation
- announce before removal
- include replacement and target removal version
Pre-release
alpha,beta,rcallowed- pre-release builds are not LTS-covered