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 cập nhật 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.

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 Ngừng hỗ trợ
Bazel 8 Không có kỳ hạn Kiểm tra trang bản phát hành ra mắt Không áp dụng
Bazel 7 Đang hoạt động 7.2.0 Tháng 12 năm 2026
Bazel 6 Đang bảo trì 6.5.0 Tháng 12 năm 2025
Bazel 5 Đang bảo trì 5.4.1 Tháng 1 năm 2025
Bazel 4 Không được tán thành 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 LTS (hỗ trợ dài hạn) của Bazel trên trang phát hành trên GitHub.

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

Bazel sử dụng giao thứ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 lớn 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 nhỏ 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).
  • Bản vá phát hành 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:

  • Lớn: 6.0.0
  • Nhỏ: 6.1.0
  • Bản vá: 6.1.2
  • Trước khi phát hành: 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ợ:

  • Rolling (Tạo bản phát hành tiếp theo): Phiên bản chính này vẫn đang ở giai đoạn phát hành trước. Nhóm Bazel sẽ phát hành các bản phát hành cuốn chiếu từ HEAD.
  • Đang hoạt động: Phiên bản chính này là bản phát hành LTS (hỗ trợ dài hạn) 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 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 điều chỉnh cho phiên bản cũ các bản sửa lỗi quan 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 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 các bản phát hành cho hai kênh phát hành.

Bản phát hành liên tục

  • Các bản phát hành liên tục đượ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 tiếp theo của Bazel LTS.
  • Các bản phát hành liên tục 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 những 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 của chúng tôi về khả năng tương thích ngược.

Bản phát hành LTS (hỗ trợ dài hạn)

  • Bản phát hành chính: Dự kiến khoảng 12 tháng một bản phát hành LTS mới sẽ bị cắt khỏi phần tử head một lần. Sau khi được phát hành, bản phát hành LTS mới, 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ỏ: 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.
  • Phát hành bản vá: Các phiên bản bản vá mới cho các bản phát hành LTS trong 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 đối với các bản sửa lỗi quan trọng.
  • Một bản phát hành LTS (hỗ trợ dài hạn) Bazel sẽ chuyển sang giai đoạn Ngừng sử dụng 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 kiểm tra các vấn đề về bản phát hành của chúng tôi 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 luân phiên, quy trình này rất đơn giản: cứ 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 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 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 hoạt động.

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

  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 lớn mới, cam kết cơ 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ở sẽ là phần đầu 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 tên là release-<version> từ cam kết cơ sở.
  3. Điều chỉnh cho phiên bản cũ các thay đổi thông qua PR đối với nhánh phát hành.
    • Cộng đồng có thể đề xuất một số thay đổi cần được điều chỉnh 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à có khả năng chặn bản phát hành. Nhóm Bazel sẽ phân loại các thay đổi đó và quyết định xem có nên điều chỉnh lại các thay đổi này 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 ngược dòng, các thay đổi nhỏ bổ sung để giải quyết xung đột hợp nhất được chấp nhận.
  4. Điều chỉnh ngược dòng (backport) các thay đổi bằng cách sử dụng vấn đề liên quan đến yêu cầu chọn anh đào đối với các nhà bảo trì Bazel.

    • Các trình bảo trì Bazel có thể yêu cầu chọn(các) lệnh xác nhận cụ thể cho 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 anh đào trên GitHub. Sau đây là cách thực hiện.

      1. Mở yêu cầu chọn quả anh đào
      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ã cam kết: Nhập(các) mã của(các) lệnh xác nhận mà bạn muốn chọn. 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.
        • (Những) người đánh giá: Đối với nhiều người đánh giá, hãy phân tách các mã nhận dạng GitHub của họ bằng dấu phẩy.
      3. Đặt mốc quan trọng
        • Tìm mục "Mốc quan trọng" rồi nhấp vào chế độ cài đặt.
        • Chọn trình chặn phát hành X.Y.Z phù hợp. Thao tác này sẽ kích hoạt bot cherry-pick để xử lý yêu cầu của bạn cho nhánh "release-X.Y.Z".
      4. Gửi vấn đề
        • Sau khi bạn điền tất cả thông tin chi tiết và thiết lập thành phần, hãy gửi vấn đề.
    • Bot chọn anh đào sẽ xử lý yêu cầu và thông báo nếu(các) cam kết đủ điều kiện để chọn anh đào. Nếu các cam kết có thể được chọn, tức là không có xung đột hợp nhất nào trong khi chọn cam kết, thì bot sẽ tạo một yêu cầu kéo mới. Khi yêu cầu lấy dữ liệu được một thành viên của nhóm Bazel phê duyệt, các thay đổi sẽ được chọn 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 ảnh anh đào đã hoàn tất, hãy tham khảo ví dụ này.

  5. Xác định trình chặn phát hành và khắc phục các vấn đề tìm thấy 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 postsubmitquy 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 sau khi bạn đã giải quyết 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 thông báo trên bazel-discuss (nhóm Bazel theo dõi các báo cáo lỗi của cộng đồng về ứng viên).
    • 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 bản phát hành dùng thử mới sau khi giải quyết xong mọi vấn đề.
    • Bạn không được phép thêm các tính năng mới vào nhánh bản phát hành sau khi tạo bản phát hành dùng thử đầu tiên; số lần được chọn chỉ được giới hạn ở các bản sửa lỗi quan trọng. Nếu cần tự chọn, 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 rất quan trọng và nó mang lại những lợi ích gì? Thay đổi này có khả năng gây ra sự hồi quy là bao nhiêu?
  7. Đẩ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 đẩy bản phát hành ra ít nhất 2 ngày làm việc sau khi bản phát hành dùng thử gần nhất được ra mắt.
    • Đối với các bản phát hành lớn và nhỏ, hãy đẩy 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 đâ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 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 thảo luận, nhóm Bazel sẽ giám sát 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 lần hồi quy

Nếu người dùng thấy có sự hồi quy trong một bản phát hành mới của Bazel, bản phát hành đề xuất 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 đôi phạm vi cam kết 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 thứ hai dùng thử 6.2.0, bạn có thể 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 chi tiết, 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 chia đôi.

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 của quy tắc.