Mô hình phát hành

Báo cáo sự cố Xem nguồn

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

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

Bazel sử dụng lược đồ Tạo 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 chính của Bazel đều là một bản phát hành LTS (hỗ trợ dài hạn).
  • Bản phát hành phụ chứa các bản sửa lỗi và tính năng có khả năng tương thích ngược được điều chỉnh từ nhánh main (chính).
  • Một 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 lớn tiếp theo.

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

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

Giai đoạn hỗ trợ

Mỗi phiên bản chính của Bazel sẽ có bốn giai đoạn hỗ trợ:

  • Phát hành: Phiên bản lớn này vẫn đang ở giai đoạn phát hành trước. Nhóm phụ trách Bazel đã phát hành các bản phát hành ra mắt từ HEAD.
  • Đang hoạt động: Phiên bản lớn này là bản phát hành LTS hiện đang hoạt động. Nhóm Bazel điều chỉnh cho phiên bản cũ các tính năng quan trọng và bản sửa lỗi cho các bản phát hành nhỏ.
  • Bảo trì: Phiên bản lớn 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 đưa vào phiên bản LTS (hỗ trợ dài hạn) cho phiên bản cũ các bản sửa lỗi quan trọng về bảo mật và khả năng tương thích với hệ điều hành.
  • Không dùng nữa: Nhóm Bazel không còn hỗ trợ phiên bản lớn 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 hai kênh phát hành.

Bản phát hành ra mắt

  • Các bản phát hành luân phiên được phối hợp với bản phát hành Google Blaze và được phát hành qua 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 tiếp theo của Bazel LTS.
  • Bản phát hành luân phiên có thể dẫn đến những thay đổi không tương thích. Bạn nên sử dụng cờ không tương thích cho những thay đổi lớn có thể gây lỗi. 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 (hỗ trợ dài hạn)

  • Bản phát hành chính: Một bản phát hành LTS mới dự kiến sẽ bị cắt khỏi HEAD khoảng 12 tháng một lần. Sau khi bản phát hành LTS mới được phát hành, bản phát hành đó sẽ ngay lập tức chuyển sang giai đoạn Đang 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ỏ: Các phiên bản nhỏ mới trên kênh LTS đang hoạt động dự kiến sẽ được phát hành 2 tháng một lần.
  • Bản vá: Các phiên bản bản vá mới cho các bản phát hành LTS ở giai đoạn Đang 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 bản sửa lỗi quan trọng.
  • Bản phát hành LTS (hỗ trợ dài hạn) Bazel chuyển sang giai đoạn Deprecated (Không dùng nữa) sau khi ở giai đoạn Bảo trì được 2 năm.

Đối với các bản phát hành theo kế hoạch, vui lòng xem các vấn đề về bản phát hành của chúng tôi trên GitHub.

Ma trận hỗ trợ

Bản phát hành LTS (hỗ trợ dài hạn) Giai đoạn hỗ trợ Phiên bản mới nhất Kết thúc hỗ trợ
Bazel 7 Không có kỳ hạn Kiểm tra trang phát hành GitHub Không áp dụng
Bazel 6 Đang hoạt động 6.4.0 Tháng 12/2025
Bazel 5 Đang bảo trì 5.4.1 Tháng 1 năm 2025
Bazel 4 Đang bảo trì 4.2.4 Tháng 1 năm 2024

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

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

Đối với các bản phát hành phát hành, quy trình này 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 cùng một đường cơ sở như bản phát hành Bluze 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 cho phiên bản cũ bất kỳ thay đổi nào đối với các bản phát hành đang được triển khai.

Đố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 cam kết cơ sở cho bản phát hành.
    • Đối với một bản phát hành LTS chính mới, cam kết cơ sở sẽ là HEAD của nhánh chính.
    • Đối với một bản phát hành nhỏ hoặc bản vá, cam kết 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 (hỗ trợ dài hạn).
  2. Tạo một nhánh phát hành dưới tên release-<version> từ cam kết cơ sở.
  3. Điều chỉnh cho phiên bản cũ các thay đổi qua PR cho nhánh phát hành.
    • Cộng đồng có thể đề xuất một số thay đổi nhất định để được chuyển lại bằng cách trả lời "@bazel-io flag" về các vấn đề hoặc PR có liên quan trên GitHub để đánh dấu các thay đổi đó là 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 xem có nên chuyển lại các thay đổi đó hay không.
    • Chỉ các thay đổi tương thích ngược trên nhánh main mới có thể được điều chỉnh cho phiên bản cũ. Bạn có thể chấp nhận các thay đổi nhỏ bổ sung để giải quyết xung đột hợp nhất.
  4. Xác định các trình chặn bản phát hành và khắc phục những vấn đề phát hiện được trên nhánh bản phát hành.
    • Nhánh bản phát hành được kiểm thử bằng cùng một bộ thử nghiệm trong postsubmitquy trình thử nghiệm hạ nguồn trên Bazel CI. Đội ngũ 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.
  5. Tạo một bản phát hành dùng thử mới từ nhánh bản phát hành sau khi khắc phục xong tất cả các trình chặn bản phát hành đã biết.
    • Bản phát hành dùng thử sẽ được công bố trên bazel-discuss, nhóm Bazel sẽ giám sát các báo cáo lỗi trong cộng đồng cho đề xuất đó.
    • Nếu xác định đượ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 dùng thử mới sau khi giải quyết xong mọi vấn đề.
    • Các tính năng mới không được phép thêm vào nhánh phát hành sau khi tạo bản phát hành đề xuất đầu tiên.
  6. Đẩy bản phát hành dùng thử dưới dạng bản phát hành chính thức nếu không tìm thấy thêm trình chặn bản phát hành nào
    • Đối với các bản phát hành của bản vá, hãy ra mắt bản phát hành ít nhất 2 ngày làm việc sau khi bản phát hành dùng thử gần đây nhất ra mắt.
    • Đối với các bản phát hành lớn và nhỏ, hãy ra mắt bản phát hành hai ngày làm việc sau khi bản phát hành dùng thử gần 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 đầu tiên dùng thử.
    • Bản phát hành chỉ được phát hành vào 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 sẽ giám sát và xử lý 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 tìm thấy sự hồi quy trong một bản phát hành Bazel mới, bản phát hành dùng thử hoặc thậm chí là Bazel tại HEAD, vui lòng báo cáo lỗi trên GitHub. Bạn có thể sử dụng Bazelisk để chia nhỏ phạm vi của thủ phạm 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 dùng thử thứ hai là 6.2.0, bạn có thể thực hiện chia đôi thông 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 sự cố. Để biết thêm thông tin, hãy xem tài liệu về tính năng chia đôi 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 các phiên bản Bazel khác nhau, vui lòng xem trang Khả năng tương thích với quy tắc.