Pre-release and Beta Changelogs
Generate changelogs for pre-release versions like alpha, beta, and release candidates with appropriate SemVer identifiers.
Detailed Explanation
Pre-release Version Changelogs
Pre-release versions (alpha, beta, release candidate) use SemVer pre-release identifiers. These communicate that the version is not yet stable and may contain breaking changes between pre-release iterations.
Pre-release Identifier Format
SemVer pre-release identifiers are appended with a hyphen:
| Stage | Version Example | Stability |
|---|---|---|
| Alpha | 2.0.0-alpha.1 |
Unstable, API may change |
| Beta | 2.0.0-beta.1 |
Feature-complete, bugs expected |
| Release Candidate | 2.0.0-rc.1 |
Near-final, critical bugs only |
| Stable | 2.0.0 |
Production-ready |
Generating a Beta Changelog
Enter the pre-release version in the generator's version field:
feat(api): add new pagination endpoints
feat(ui): redesign settings page
fix(api): handle empty responses correctly
feat(api)!: change auth header format
With version 2.0.0-beta.1, the output becomes:
## [2.0.0-beta.1] - 2026-02-27
### BREAKING CHANGES
- **api:** change auth header format
### Added
- **api:** add new pagination endpoints
- **ui:** redesign settings page
### Fixed
- **api:** handle empty responses correctly
Progressive Changelogs
For projects with multiple pre-release iterations, generate a changelog for each:
## [2.0.0-beta.2] - 2026-03-10
### Fixed
- **api:** correct pagination offset calculation
## [2.0.0-beta.1] - 2026-02-27
### Added
- **api:** add new pagination endpoints
Promoting to Stable
When you release the stable version (2.0.0), consolidate all pre-release changes into a single changelog entry. Run the generator with all commits since the last stable release to produce a comprehensive 2.0.0 entry.
Use Case
For projects in active development that publish pre-release versions to early adopters. Pre-release changelogs set expectations about stability and help testers understand what to focus on.