-
Notifications
You must be signed in to change notification settings - Fork 12
Versioning
Generally speaking, our version numbering approach follows the Semantic Versioning specifications (SemVer).
Note that the “marketing” format of version numbers can be different from the one defined by SemVer. The following is the rule of thumb:
-
Code version number: must follow SemVer strictly. It must be used on “code representation” of versions, like branches and tag names, file names or any other place made for machine reading.
-
Marketing version number: can be used on websites, blogs, social, packaging and any material destined to people to read.
For example, SemVer versions 1.0.0 and 1.1.0-beta.1 could have their marketing names relatively “1” and “1.1 Beta 1”.
All sub-projects that support the development of CKEditor 5 components follow SemVer rules strictly. This is essential, considering that CKEditor 5 is based on npm for the resolution of dependencies between components.
Releases of CKEditor 5 are basically builds made out of several components, each one having its own version number. Therefore the CKEditor core team, which is responsible for periodic releases, apply a dedicated version number to each release, all of them start with the "5" major release number.
We still want to give some semantic value to release numbers, even if we're forcing the first part of them to be static. Additionally, we want to enable end-developers to use package managers, like Bower, to have CKEditor on their environments. Therefore, release numbers follow a SemVer-like scheme.
Using the SemVer terminology, CKEditor 5 release versions follow this scheme:
5.MAJOR-or-MINOR.PATCH
This means that variations on the "PATCH" part should be easily absorbed when upgrading, while new features and API-incompatible changes are expected to change the "MAJOR-or-MINOR" part.