Mô hình phát hành

Như đã thông báo trong bài đăng ban đầu trên blog, Bazel phiên bản 4.0 trở lên hỗ trợ hai kênh phát hành: bản phát hành lăn và bản phát hành hỗ trợ dài hạn (LTS). Trang này trình bày thông tin mới nhất về mô hình phát hành của Bazel.

Ma trận hỗ trợ

Bạn có thể tìm thấy tất cả bản phát hành LTS của Bazel trên trang phát hành trên GitHub.

Tạo phiên bản phát hành

Bazel sử dụng lược đồ Định nghĩa phiên bản ngữ nghĩa major.minor.patch.

• Bản phát hành chính chứa các tính năng không tương thích ngược với bản phát hành trước. Mỗi phiên bản Bazel chính là một bản phát hành LTS.
• Bản phát hành nhỏ chứa các bản sửa lỗi và tính năng tương thích ngược được điều chỉnh cho phù hợp từ nhánh chính.
• Bản phát hành bản vá chứa các bản sửa lỗi quan trọng.

Ngoài ra, các phiên bản phát hành trước được biểu thị bằng cách thêm dấu gạch nối và hậu tố ngày vào số phiên bản chính tiếp theo.

Ví dụ: một bản phát hành mới của mỗi loại sẽ dẫn đến các số phiên bản sau:

• Chính: 6.0.0
• Phiên bản nhỏ: 6.1.0
• Bản vá: 6.1.2
• Bản phát hành trước: 7.0.0-pre.20230502.1

Các giai đoạn hỗ trợ

Đối với mỗi phiên bản Bazel chính, có 4 giai đoạn hỗ trợ:

• Tiến hành phát hành liên tục: Phiên bản chính này vẫn đang trong giai đoạn phát hành trước, nhóm Bazel phát hành các bản phát hành liên tục từ HEAD.
• Đang hoạt động: Phiên bản chính này là bản phát hành LTS đang hoạt động hiện tại. Nhóm Bazel sẽ điều chỉnh các tính năng quan trọng và bản sửa lỗi vào các bản phát hành nhỏ.
• Bảo trì: Phiên bản chính này là một bản phát hành LTS cũ ở chế độ bảo trì. Nhóm Bazel chỉ hứa hẹn sẽ điều chỉnh các bản sửa lỗi nghiêm trọng cho các vấn đề về bảo mật và khả năng tương thích với hệ điều hành vào bản phát hành LTS này.
• Không dùng nữa: Nhóm Bazel không còn hỗ trợ phiên bản chính này nữa, tất cả người dùng nên chuyển sang các bản phát hành Bazel LTS mới hơn.

Tần suất phát hành

Bazel thường xuyên phát hành các bản phát hành cho hai kênh phát hành.

Bản phát hành lăn

• Bản phát hành lăn được điều phối với bản phát hành Google Blaze và được phát hành từ HEAD khoảng hai tuần một lần. Đây là bản xem trước của bản phát hành Bazel LTS tiếp theo.
• Bản phát hành lăn có thể gửi các thay đổi không tương thích. Bạn nên sử dụng cờ không tương thích cho các thay đổi có thể gây lỗi lớn. Việc triển khai các thay đổi không tương thích phải tuân theo chính sách về khả năng tương thích ngược của chúng tôi.

Bản phát hành LTS

• Bản phát hành chính: Dự kiến mỗi 12 tháng sẽ có một bản phát hành LTS mới được cắt từ HEAD. Sau khi bản phát hành LTS mới ra mắt, bản phát hành đó sẽ ngay lập tức chuyển sang giai đoạn Hoạt động và bản phát hành LTS trước đó sẽ chuyển sang giai đoạn Bảo trì.
• Bản phát hành nhỏ: Dự kiến, các phiên bản nhỏ mới trên kênh LTS đang hoạt động sẽ được phát hành 2 tháng một lần.
• Bản phát hành bản vá: Các phiên bản bản vá mới cho bản phát hành LTS ở giai đoạn Hoạt động và Bảo trì dự kiến sẽ được phát hành theo yêu cầu để sửa các lỗi nghiêm trọng.
• Bản phát hành LTS của Bazel sẽ chuyển sang giai đoạn Ngừng sử dụng sau khi ở giai đoạn Bảo trì trong 2 năm.

Đối với các bản phát hành theo kế hoạch, vui lòng kiểm tra các vấn đề về bản phát hành trên GitHub.

Quy trình phát hành và chính sách

Đối với bản phát hành lăn, quy trình rất đơn giản: khoảng hai tuần một lần, một bản phát hành mới sẽ được tạo, phù hợp với đường cơ sở giống như bản phát hành Blaze nội bộ của Google. Do lịch phát hành nhanh chóng, chúng tôi không điều chỉnh ngược bất kỳ thay đổi nào cho các bản phát hành lăn.

Đối với các bản phát hành LTS, quy trình và chính sách dưới đây sẽ được tuân thủ:

1. Xác định một thay đổi cơ sở cho bản phát hành.
   • Đối với bản phát hành LTS chính mới, thay đổi cơ sở là HEAD của nhánh chính.
   • Đối với bản phát hành nhỏ hoặc bản vá, thay đổi cơ sở là HEAD của phiên bản mới nhất hiện tại của cùng một bản phát hành LTS.
2. Tạo một nhánh phát hành có tên là release-<version> từ thay đổi cơ sở.
3. Điều chỉnh các thay đổi cho các phiên bản cũ thông qua yêu cầu phát hành (PR) cho nhánh phát hành.
   • Cộng đồng có thể đề xuất một số thay đổi nhất định được điều chỉnh cho phiên bản cũ bằng cách trả lời "@bazel-io flag" trên các vấn đề hoặc yêu cầu phát hành có liên quan trên GitHub để đánh dấu các thay đổi đó là các trình chặn bản phát hành tiềm ẩn. Nhóm Bazel sẽ phân loại các thay đổi đó và quyết định có điều chỉnh cho phiên bản cũ các thay đổi đó hay không.
   • Chỉ những thay đổi tương thích ngược trên nhánh chính mới có thể được điều chỉnh cho phiên bản cũ. Bạn có thể chấp nhận thêm một số thay đổi nhỏ để giải quyết xung đột hợp nhất.

4. Điều chỉnh các thay đổi cho phiên bản cũ bằng cách sử dụng vấn đề Yêu cầu chọn lọc cho các trình bảo trì Bazel.

   • Người duy trì Bazel có thể yêu cầu chọn lọc (cherry-pick) (các) thay đổi cụ thể vào một nhánh phát hành. Quy trình này được bắt đầu bằng cách tạo một yêu cầu chọn lọc trên GitHub. Sau đây là cách thực hiện.

     1. Mở yêu cầu chọn lọc
     2. Điền thông tin chi tiết về yêu cầu
        • Tiêu đề: Cung cấp tiêu đề ngắn gọn và mô tả cho yêu cầu.
        • (Các) mã nhận dạng thay đổi: Nhập(các) mã nhận dạng của(các) thay đổi mà bạn muốn chọn lọc. Nếu có nhiều thay đổi, hãy phân tách các thay đổi đó bằng dấu phẩy.
        • Danh mục: Chỉ định danh mục của yêu cầu.
        • (Các) người đánh giá: Đối với nhiều người đánh giá, hãy phân tách mã nhận dạng GitHub của họ bằng dấu phẩy.
     3. Đặt cột mốc
        • Tìm phần "Mốc" rồi nhấp vào chế độ cài đặt.
        • Chọn trình chặn bản phát hành X.Y.Z phù hợp. Thao tác này kích hoạt bot chọn lọc để xử lý yêu cầu của bạn cho nhánh "release-X.Y.Z".
     4. Gửi vấn đề
        • Sau khi điền tất cả thông tin chi tiết và đặt mục tiêu, hãy gửi vấn đề.

   • Bot chọn lọc sẽ xử lý yêu cầu và thông báo nếu(các) thay đổi đó đủ điều kiện để chọn lọc. Nếu bạn có thể chọn các thay đổi trong các thay đổi đã cam kết, tức là không có xung đột hợp nhất trong khi chọn các thay đổi trong các thay đổi đã cam kết, thì bot sẽ tạo một yêu cầu kéo mới. Khi một thành viên của nhóm Bazel phê duyệt yêu cầu rút, các thay đổi sẽ được chọn lọc và hợp nhất vào nhánh phát hành. Để xem ví dụ trực quan về một yêu cầu chọn lọc đã hoàn tất, hãy tham khảo ví dụ này.

5. Xác định các yếu tố chặn bản phát hành và khắc phục các vấn đề phát hiện được trên nhánh phát hành.

   • Nhánh phát hành được kiểm thử bằng cùng một bộ kiểm thử trong postsubmit và quy trình kiểm thử hạ nguồn trên Bazel CI. Nhóm Bazel theo dõi kết quả kiểm thử của nhánh phát hành và khắc phục mọi lỗi hồi quy phát hiện được.

6. Tạo một bản phát hành đề xuất mới từ nhánh phát hành khi tất cả các trình chặn bản phát hành đã biết đều được giải quyết.

   • Bản phát hành dùng thử được công bố trên bazel-discuss, nhóm Bazel theo dõi các báo cáo lỗi của cộng đồng cho bản phát hành dùng thử.
   • Nếu phát hiện thấy các trình chặn bản phát hành mới, hãy quay lại bước cuối cùng và tạo một bản phát hành đề xuất mới sau khi giải quyết tất cả các vấn đề.
   • Không được thêm tính năng mới vào nhánh phát hành sau khi tạo bản phát hành đề xuất đầu tiên; chỉ được chọn lọc các bản sửa lỗi quan trọng. Nếu cần chọn lọc, người yêu cầu phải trả lời các câu hỏi sau: Tại sao thay đổi này lại quan trọng và thay đổi này mang lại lợi ích gì? Sự thay đổi này có khả năng gây ra hồi quy hay không?

7. Đẩy bản phát hành dùng thử làm bản phát hành chính thức nếu không tìm thấy trình chặn bản phát hành nào khác

   • Đối với bản phát hành bản vá, hãy đẩy bản phát hành ít nhất 2 ngày làm việc sau khi bản phát hành đề xuất cuối cùng được phát hành.
   • Đối với bản phát hành chính và phụ, hãy đẩy bản phát hành 2 ngày làm việc sau khi bản phát hành đề xuất gần đây nhất được phát hành, nhưng không sớm hơn một tuần sau khi bản phát hành đề xuất đầu tiên được phát hành.
   • Bản phát hành chỉ được đẩy vào một ngày mà ngày tiếp theo là ngày làm việc.
   • Bản phát hành được công bố trên bazel-discuss, nhóm Bazel theo dõi và giải quyết các báo cáo lỗi của cộng đồng cho bản phát hành mới.

Báo cáo hồi quy

Nếu người dùng phát hiện thấy sự hồi quy trong bản phát hành Bazel mới, bản phát hành đề xuất hoặc thậm chí là Bazel tại HEAD, vui lòng gửi lỗi trên GitHub. Bạn có thể sử dụng Bazelisk để phân chia lần cam kết gây ra lỗi và đưa thông tin này vào báo cáo lỗi.

Ví dụ: nếu bản dựng của bạn thành công với Bazel 6.1.0 nhưng không thành công với bản phát hành đề xuất thứ hai của 6.2.0, thì bạn có thể phân chia qua

bazelisk --bisect=6.1.0..release-6.2.0rc2 build //foo:bar

Bạn có thể đặt biến môi trường BAZELISK_SHUTDOWN hoặc BAZELISK_CLEAN để chạy các lệnh bazel tương ứng nhằm đặt lại trạng thái bản dựng nếu cần để tái hiện vấn đề. Để biết thêm thông tin, hãy xem tài liệu về tính năng phân chia của Bazelisk.

Hãy nhớ nâng cấp Bazelisk lên phiên bản mới nhất để sử dụng tính năng bisect.

Khả năng tương thích của quy tắc

Nếu bạn là tác giả quy tắc và muốn duy trì khả năng tương thích với nhiều phiên bản Bazel, vui lòng xem trang Khả năng tương thích với quy tắc.