Warum gibt es in der offiziellen Dokumentation mehrere Zweige (z. B. 8.0.x, 8.1.x)?

Warum gibt es in der offiziellen Dokumentation mehrere Zweige (z. B. 8.0.x, 8.1.x) ?

Ist geplant, dass Unterversionen von Drupal 8 unabhängig voneinander entwickelt werden?

Wenn ja, worum geht es dann?
Wenn nein, warum werden diese Zweige dann in der Dokumentation erwähnt?

Drupal 8 wechselte zur semantischen Versionierung und zu einem kürzeren Release-Zyklus zwischen Nebenversionen.

Gemäß Release-Richtlinie kann es Unterschiede zwischen kleineren Versionen geben. Im Allgemeinen sind neue Nebenversionen abwärtskompatibel (oder bieten eine BC-Ebene), können jedoch auch neue Funktionen einführen. Wenn kleinere Versionen veröffentlicht werden, bleiben einige Funktionen erhalten, werden jedoch nicht mehr unterstützt.

Aus diesem Grund gibt es unterschiedliche Dokumentationen für verschiedene Nebenversionen. Das Dokument ist tatsächlich etwas anders.

Um über Änderungen in Drupal 8 auf dem Laufenden zu bleiben, überwachen Sie die Liste der Änderungsdatensätze oder das Twitter-Konto , das jedes neue ankündigt.

Dies ist eine Änderung der Richtlinien gegenüber früheren Drupal-Versionen. Neuer Code und neue API können und wurden in kleineren Versionen veröffentlicht. Die API-Seiten sind erforderlich, damit in kleineren Versionen nach bestimmten APIs gesucht werden kann, da eine kleinere Version möglicherweise noch gültig ist.

https://www.drupal.org/core/d8-allowed-changes#minor

Drupal 8 führt einen sechsmonatigen kleinen Release-Zyklus ein. Kleinere Releases bieten neue Verbesserungen und Funktionen, ohne die Abwärtskompatibilität (BC) für öffentliche APIs zu beeinträchtigen. Die folgenden Arten von Änderungen sind für kleinere Releases zusätzlich zu den für Patch-Releases zulässigen zulässig. Beispielsweise werden diese Änderungen nach der Veröffentlichung von 8.1.0 nicht für 8.1.x festgeschrieben, sondern können für die Aufnahme in 8.2.0 an 8.2.x festgeschrieben werden.

https://www.drupal.org/core/d8-bc-policy

Kleinere Versionen (8.x.0) können Refactoring ohne API-Unterbrechung, neue Funktionen oder Verbesserungen vorhandener Funktionen enthalten. In solchen Fällen wird das Kernteam sicherstellen, dass diese Verbesserungen die vorhandene öffentlich zugängliche API von Kernsystemen nicht verändern.

Die erforderliche Sicherheitshärtung hat Vorrang vor der API-Stabilität.

Wir werden alle Anstrengungen unternehmen, um Sicherheitsprobleme zu beheben, ohne die öffentliche API zu beeinträchtigen. In einigen Fällen ist es jedoch nicht möglich, eine Sicherheitslücke ohne eine API-Änderung zu beheben. In solchen Fällen werden wir daran arbeiten, den Umfang der API-Änderung zu minimieren und gründlich zu dokumentieren.

Dies liegt daran, dass die API Änderungen in jeder dieser Versionen einführen und neue Kernmodule oder experimentelle Kernmodule einführen kann (die öffentlich getestet werden und später Teil des Kerns werden oder zu Beiträgen übergehen können). Das sind nur einige Gründe.