Release Notes Following Semantic Versioning

Release Notes and Semantic Versioning

Semantic Versioning (SemVer) gives version numbers meaning. Your release notes should reinforce that meaning by including the right type of changes for each version bump.

Version Number Meanings

MAJOR.MINOR.PATCH (e.g., 2.3.1)
  |     |     |
  |     |     +-- Bug fixes only (backward compatible)
  |     +-------- New features (backward compatible)
  +-------------- Breaking changes (not backward compatible)

What Each Release Type Should Contain

Patch Release (x.y.Z)

## [1.2.3] - 2026-02-28

### Fixed
- Fix timeout in connection retry logic (#456)
- Correct off-by-one error in pagination (#459)

Only Fixed and Security categories. No new features, no behavior changes.

Minor Release (x.Y.0)

## [1.3.0] - 2026-02-28

### Added
- New caching layer with Redis support (#500)
- CLI flag for verbose output (#503)

### Changed
- Improve error messages with stack traces (#501)

### Deprecated
- `oldMethod()` — use `newMethod()` instead (#504)

### Fixed
- Fix memory leak in event handler (#498)

Can include Added, Changed, Deprecated, and Fixed. No breaking changes.

Major Release (X.0.0)

## [2.0.0] - 2026-02-28

### BREAKING CHANGES
> `initialize()` now requires a config object.

### Added
- Complete rewrite of core engine
- New plugin system

### Removed
- Legacy API methods deprecated in v1.3

Can include anything, but must have breaking changes to justify the major bump.

Pre-release Identifiers

2.0.0-alpha.1  — Early testing, APIs may change
2.0.0-beta.1   — Feature complete, testing phase
2.0.0-rc.1     — Release candidate, final testing
2.0.0          — Stable release

Each pre-release should have its own notes documenting what changed since the previous pre-release.