Tại sao có một số chi nhánh tại tài liệu chính thức (ví dụ 8.0.x, 8.1.x)?

Tại sao có một số chi nhánh (ví dụ 8.0.x, 8.1.x) tại tài liệu chính thức ?

Có kế hoạch rằng các phiên bản phụ của Drupal 8 sẽ được phát triển độc lập không?

Nếu có, thì vấn đề là gì?
Nếu không, tại sao các chi nhánh được đề cập trong tài liệu này?

Drupal 8 đã chuyển sang phiên bản ngữ nghĩa và chu kỳ phát hành ngắn hơn giữa các phiên bản nhỏ.

Mỗi chính sách phát hành, có thể có sự khác biệt giữa các phiên bản nhỏ. Nhìn chung, các phiên bản nhỏ mới tương thích ngược (hoặc cung cấp lớp BC), nhưng cũng có thể giới thiệu các tính năng mới. Ngoài ra, khi các phiên bản nhỏ được phát hành, một số chức năng vẫn còn nhưng không được dùng nữa.

Đây là lý do tại sao có tài liệu khác nhau cho các phiên bản nhỏ khác nhau; tài liệu thực sự là hơi khác nhau.

Để theo kịp các thay đổi trong Drupal 8, hãy theo dõi danh sách Bản ghi thay đổi hoặc tài khoản Twitter thông báo từng thay đổi mới.

Đây là một sự thay đổi trong chính sách từ các phiên bản Drupal trước đó. Mã và API mới có thể và đã được phát hành trong các bản phát hành nhỏ. Các trang API là cần thiết để có thể tra cứu API cụ thể trong các bản phát hành nhỏ vì một bản phát hành nhỏ vẫn có thể hợp lệ.

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

Drupal 8 giới thiệu chu kỳ phát hành nhỏ sáu tháng. Các bản phát hành nhỏ cung cấp các cải tiến và chức năng mới mà không phá vỡ tính tương thích ngược (BC) cho các API công khai. Các loại thay đổi sau đây được phép cho các bản phát hành nhỏ ngoài những loại được phép cho bản phát hành bản vá. Ví dụ: sau khi phát hành 8.1.0, những thay đổi này sẽ không được cam kết với 8.1.x, nhưng thay vào đó có thể được cam kết thành 8.2.x để đưa vào 8.2.0.

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

Các bản phát hành nhỏ (8.x.0) có thể bao gồm tái cấu trúc không phá vỡ API, các tính năng mới hoặc cải tiến các tính năng hiện có. Trong những trường hợp như vậy, nhóm nòng cốt sẽ làm việc để đảm bảo rằng những cải tiến này không làm thay đổi API đối mặt công khai hiện có của các hệ thống cốt lõi.

Việc tăng cường bảo mật cần thiết được ưu tiên hơn tính ổn định của API.

Chúng tôi sẽ cố gắng hết sức để giải quyết các vấn đề bảo mật mà không ảnh hưởng đến API công khai. Tuy nhiên, trong một số trường hợp, sẽ không thể giải quyết lỗ hổng bảo mật nếu không có thay đổi API. Trong những trường hợp như vậy, chúng tôi sẽ làm việc để giảm thiểu phạm vi thay đổi API và ghi lại kỹ lưỡng.

Đó là vì API có thể giới thiệu các thay đổi trong từng phiên bản đó và giới thiệu các mô-đun lõi mới hoặc mô-đun thử nghiệm lõi (được thử nghiệm công khai và sau đó có thể trở thành một phần của lõi hoặc chuyển sang đóng góp). Đó chỉ là một vài lý do.