Versioning policy

CKEditor 5 is a modular ecosystem of over 80 packages, distributed through npm. To provide predictability and a consistent developer experience, we follow a unified versioning and release policy across all packages.

CKEditor 5 is delivered in two core packages:

• ckeditor5 – the framework and open-source features.
• ckeditor5-premium-features – commercial plugins and add-ons.

Together, these aggregate and version over 80 underlying packages that make up the editor framework, features, and utilities.

In addition, the ecosystem provides separately versioned integration packages and tooling:

• Integrations: @ckeditor/ckeditor5-react, @ckeditor/ckeditor5-angular, @ckeditor/ckeditor5-vue
• Tooling: ckeditor5-package-generator, @ckeditor/ckeditor5-integrations-common

• All CKEditor 5 packages share the same version number.
• This includes both ckeditor5 and ckeditor5-premium-features, as well as all underlying feature and framework packages.
• Integration packages and tooling may follow their own versioning, but major compatibility notes are always documented.

This unified versioning approach is common in large ecosystems (for example, Angular). It simplifies dependency management, avoids mismatched versions, and makes it easy to know which packages are compatible.

All packages in the ecosystem pin dependencies to specific versions. This prevents issues with npm/yarn/pnpm resolving past versions incorrectly and guarantees reproducible builds.

We use the MAJOR.MINOR.PATCH scheme:

• MAJOR – Introduced when at least one package requires a major breaking change. This affects the entire ecosystem.
• MINOR – Introduced when a package adds a new feature or introduces a minor breaking change.
• PATCH – Introduced when a package only includes bug fixes, internal changes, or documentation updates.

Because CKEditor 5 spans multiple layers – from low-level utilities through framework APIs to ready-to-use builds – our approach differs from strict Semantic Versioning. Instead, our policy balances stability with the flexibility needed for such a broad ecosystem.

Breaking changes are categorized based on which layer of the ecosystem they affect:

• Integration layer (editor builds, configuration, and top-level APIs):
  • Breaking changes are considered major.
  • Introduced very rarely and only when unavoidable.
• Plugin development API (packages such as @ckeditor/ckeditor5-engine or @ckeditor/ckeditor5-core):
  • Breaking changes are also considered major.
  • Introduced occasionally, but batched to reduce the number of major releases.
• Low-level customization APIs and feature customization APIs (internal utilities, hooks, helper functions, and lower-level APIs exposed by specific features, for example the Link balloon):
  • Designed mainly for deep customizations of existing features, rather than for building integrations or plugins.
  • Treated as less stable – breaking changes are considered minor and may occur more often as these APIs evolve with feature development.
  • Provide powerful flexibility but are closer to implementation details, so they should not be relied upon for long-term compatibility guarantees.

We typically publish a new major release of CKEditor 5 every 6 months, though in some cases new majors may arrive sooner. Each new major replaces the previous one as the actively supported version, ensuring that all users benefit from the latest improvements, fixes, and compatibility updates.

For projects that need long-term stability, we also offer the commercial CKEditor 5 LTS (Long-term Support) Edition. Every two years, one major release (starting with v47.0.0) is designated as an LTS release, providing up to 3 years of guaranteed updates – 6 months of active development followed by 2.5 years of maintenance with security and critical compatibility fixes. Read more in the CKEditor 5 LTS Edition guide.

CKEditor 5 is distributed through several release channels, each serving a different purpose:

• Stable releases: The recommended versions for production use. These are fully tested and supported, and are available via npm, ZIP packages, and the official CDN.
• Alpha builds: Used for early access and testing before a stable release. Alpha builds are published to npm under the alpha dist-tag.
• Nightly builds: Generated automatically from the latest development branch. They are available via npm under the nightly dist-tag and are intended for testing the newest changes.

If you encounter an issue, please report it in the CKEditor 5 issue tracker. Early feedback (especially about alpha and nightly releases) gives us more time to investigate and resolve problems before they reach a stable release.

To stay up to date with changes:

• Changelog: Check the CKEditor 5 changelog.
• News: Read the CKEditor Ecosystem Blog or subscribe to the newsletter.
• npm: Follow the ckeditor5 and ckeditor5-premium-features packages.

When a release introduces breaking or otherwise important changes, the Updating CKEditor 5 section provides technical details and migration steps. Always review these guides after a release to keep your integration stable.