// Guide through releasing a new version of kiso-icons. Use when cutting a release, publishing a new version, or running bin/release.
| name | release |
| description | Guide through releasing a new version of kiso-icons. Use when cutting a release, publishing a new version, or running bin/release. |
The bin/release script handles all the mechanical steps. Your job is the advisory layer before it runs: reviewing what changed, confirming the CHANGELOG is good, and picking the right version.
Read both files:
CHANGELOG.md — the [Unreleased] sectionlib/kiso/icons/version.rb — the current versionSummarise the unreleased changes for the user and recommend a semver bump type with reasoning:
| Bump | When |
|---|---|
| major | Breaking changes to the public API |
| minor | New features, backward compatible |
| patch | Bug fixes, docs, internal changes only |
| x.y.z.pre | Pre-stable release (current convention while < 1.0) |
Show the [Unreleased] entries and ask the user to confirm they are complete and accurate before proceeding. Entries should be:
### Added, ### Changed, ### Fixed, ### Removed as appropriateIf entries are missing or need improvement, help the user edit CHANGELOG.md now — before running the release script. The script uses the CHANGELOG entries verbatim as the GitHub Release body.
Propose a concrete version string based on the bump reasoning. Wait for the user to confirm or provide an alternative.
The current convention while the gem is pre-stable: use x.y.z.pre (e.g. 0.3.0.pre). Switch to x.y.z when declaring stable.
Run the release script in dry-run mode with the confirmed version:
bin/release --dry-run <version>
Show the full output. If any check fails (dirty tree, not on master, tests fail, etc.), stop and help resolve the issue before proceeding.
On user confirmation, run:
bin/release <version>
The script will:
lib/kiso/icons/version.rb[Unreleased] → [VERSION] - DATE in CHANGELOG.mdpre/alpha/beta/rc versions)