Release process

Releases are performed by project maintainers after the intended changes have been reviewed and merged. The process updates package metadata and the changelog, creates a Git tag and publishes the generated icon library to npm.

Before changing the version

Start from a clean, current default branch and confirm that the release contains only the changes intended for publication. Review new identifiers and aliases, check TYPO3 compatibility implications and run the complete build before selecting the version increment.

npm ci
npm run build

Use a patch release for compatible fixes, a minor release for compatible additions and a major release for breaking changes. The decision describes the public package contract, including identifiers and distributed file paths—not the amount of code changed.

Create the release commit and tag

The npm version lifecycle runs the configured preversion checks and changelog task. The project uses [RELEASE] v%s as its release commit message, and release commits are excluded from the generated changelog content.

npm version [major | minor | patch]

Inspect the version change, changelog entry and generated metadata before pushing. The tag is part of the compatibility history, so correct mistakes before it becomes public.

Publish the release

Push the reviewed release commit and its tag, then publish with an npm account authorized for @typo3/icons. Do not run these commands from an unreviewed feature branch.

git push origin main --tags
npm publish

Verify the public result

Confirm that the npm package version, Git tag and release history agree. Check that the package contains the expected individual SVGs, sprites, CSS, Sass and data files, and verify that the documentation site still resolves the released identifiers and internal navigation.

If a publication problem affects consumers, document it explicitly and follow with the smallest safe corrective release. Do not silently move or recreate a public Git tag.