8
0
Просмотр исходного кода

Updated the versioning policy guide.

Piotrek Koszuliński 5 лет назад
Родитель
Сommit
61332eebf1
1 измененных файлов с 6 добавлено и 4 удалено
  1. 6 4
      docs/framework/guides/support/versioning-policy.md

+ 6 - 4
docs/framework/guides/support/versioning-policy.md

@@ -5,16 +5,18 @@ order: 50
 
 
 # Versioning policy
 # Versioning policy
 
 
-CKEditor 5 consists of multiple npm packages (over 40, at the moment of writing this guide). When releasing them, we use the following rules:
+CKEditor 5 consists of multiple npm packages (over 50, at the moment of writing this guide). When releasing them, we use the following rules:
 
 
 * We use the `MAJOR.MINOR.PATCH` version identifiers.
 * We use the `MAJOR.MINOR.PATCH` version identifiers.
-* Each package is versioned independently, with one exception — all packages are always in the same `MAJOR` version.
-* A major release of CKEditor 5 (i.e. of all its packages) is published when at least one of its packages must have a major release. This is to ensure the previous rule.
+* All packages are always in the same version.
+* A major release of CKEditor 5 (i.e. of all its packages) is published when at least one of its packages must have a major release.
+* A minor version of CKEditor 5 (i.e. of all its packages) is published when at least one of its packages must have a minor release and none of them require a major release.
 * A package must have a major release when it contains a *major breaking change*.
 * A package must have a major release when it contains a *major breaking change*.
 * If none of the packages contain any *major breaking change*, the following rules are used to determine the new version of each package:
 * If none of the packages contain any *major breaking change*, the following rules are used to determine the new version of each package:
 	* If a package contains a *minor breaking change*, a `MINOR` version is increased.
 	* If a package contains a *minor breaking change*, a `MINOR` version is increased.
 	* If a package contains a new feature, a `MINOR` version is increased.
 	* If a package contains a new feature, a `MINOR` version is increased.
 	* If a package contains only bug fixes, unrelated changes (e.g. updated translations), documentation or other internal changes, a `PATCH` version is increased.
 	* If a package contains only bug fixes, unrelated changes (e.g. updated translations), documentation or other internal changes, a `PATCH` version is increased.
+* In order to ensure that all packages are in the same version, some releases of certain packages may be empty (no changes).
 
 
 ## Major and minor breaking changes
 ## Major and minor breaking changes
 
 
@@ -34,4 +36,4 @@ The ecosystem of CKEditor 5 consists of multiple layers. Our approach to breakin
 
 
 Prior to version 15.0.0 each package was versioned independently and followed the [semantic versioning (semver)](https://semver.org/). Following semver as close as possible was useful as it allowed to quickly identify what changed in each release of a certain package. However, it lead to [problems with building old versions of the editor](https://github.com/ckeditor/ckeditor5/issues/1746).
 Prior to version 15.0.0 each package was versioned independently and followed the [semantic versioning (semver)](https://semver.org/). Following semver as close as possible was useful as it allowed to quickly identify what changed in each release of a certain package. However, it lead to [problems with building old versions of the editor](https://github.com/ckeditor/ckeditor5/issues/1746).
 
 
-Therefore, we switched to a more commonly used practice for an ecosystem of packages, which is to treat a single breaking change as a major release of all packages. It automatically fixed the aforementioned problem in all projects that use caret ranges in their `package.json` files.
+Therefore, we switched to a more commonly used practice for an ecosystem of packages, which is to treat a single breaking change as a major release of all packages. It automatically fixed the aforementioned problem in all projects that use caret ranges in their `package.json` files. Later on, we decided that it will be even most convenient for integrators if all packages are in the exact same version, which is also not uncommon (e.g. [Angular](https://github.com/angular/angular) follows this practice).