Mô hình phát hành

Báo cáo vấn đề Xem nguồn Nightly · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

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 liên tục 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 phát hành LTS	Giai đoạn hỗ trợ	Phiên bản mới nhất	Ngừng hỗ trợ
Bazel 9	Tuyển sinh không có kỳ hạn	Kiểm tra trang phát hành liên tục	Không áp dụng
Bazel 8	Đang hoạt động	8.3.0	Tháng 12 năm 2027
Bazel 7	Đang bảo trì	7.6.1	Tháng 12 năm 2026
Bazel 6	Đang bảo trì	6.5.0	Tháng 12 năm 2025
Bazel 5	Không được dùng nữa	5.4.1	Tháng 1 năm 2025
Bazel 4	Không được dùng nữa	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 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 một lược đồ Định nghĩa phiên bản ngữ nghĩa major.minor.patch.

Bản phát hành chính có 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 đều 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 chuyển ngược 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 ngang 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ẽ có số phiên bản như sau:

Chính: 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: Phiên bản chính này vẫn đang ở 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: Đây là bản phát hành LTS đang hoạt động hiện tại. Nhóm Bazel sẽ chuyển ngược 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 phụ của Bazel.
Bảo trì: Đây là một bản phát hành LTS cũ ở chế độ bảo trì. Nhóm Bazel chỉ cam kết chuyển ngược các bản sửa lỗi nghiêm trọng đối với 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 di chuyển sang các bản phát hành LTS mới hơn của Bazel.

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 2 kênh phát hành.

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

Bản phát hành từng phần được phối hợp 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 LTS Bazel tiếp theo.
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 dùng các cờ không tương thích cho những thay đổi lớn gây ảnh hưởng đến khả năng tương thích. Việc triển khai các thay đổi không tương thích phải tuân theo chính sách 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 sẽ có một bản phát hành LTS mới được cắt từ HEAD sau khoảng 12 tháng. Sau khi một 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 Đ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 phụ: Các phiên bản phụ 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 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 Đ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 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 hỗ trợ sau 2 năm ở giai đoạn Bảo trì.

Đố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.

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

Đối với các bản phát hành liên tục, quy trình này khá đơ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 đường cơ sở như bản phát hành Blaze nội bộ của Google. Do lịch phát hành nhanh, chúng tôi không chuyển ngược bất kỳ thay đổi nào sang các bản phát hành liên tục.

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

Xác định một 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ở là HEAD của nhánh chính.
- Đối với bản phát hành phụ hoặc bản phát hành vá lỗi, cam kết cơ sở là HEAD của phiên bản LTS mới nhất hiện tại.
Tạo một nhánh phát hành có tên là release-<version> từ cam kết cơ sở.
Chuyển các thay đổi qua PR sang nhánh phát hành.
- Cộng đồng có thể đề xuất một số cam kết cần được chuyển ngược bằng cách trả lời "@bazel-io flag" trên các vấn đề hoặc yêu cầu kéo có liên quan trên GitHub để đánh dấu các cam kết đó là những yếu tố có thể chặn việc phát hành. Nhóm Bazel sẽ phân loại các cam kết đó và quyết định xem có chuyển ngược các cam kết đó hay không.
- Chỉ những cam kết tương thích ngược trên nhánh chính mới có thể được chuyển ngược, bạn có thể thực hiện thêm các thay đổi nhỏ để giải quyết xung đột khi hợp nhất.
Backport changes using Cherry-Pick Request Issue for Bazel maintainers.
- Người duy trì Bazel có thể yêu cầu chọn lọc (cherry-pick) (các) cam kết cụ thể cho một nhánh phát hành. Quy trình này bắt đầu bằng việc 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 đề: Đặt một tiêu đề ngắn gọn và mang tính mô tả cho yêu cầu.
    - Mã cam kết: Nhập mã của (các) cam kết mà bạn muốn chọn lọc. Nếu có nhiều cam kết, hãy phân tách chúng bằng dấu phẩy.
    - Danh mục: Chỉ định danh mục của yêu cầu.
    - Người đánh giá: Nếu có 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 "Cột mốc" rồi nhấp vào chế độ cài đặt.
    - Chọn các vấn đề chặn bản phát hành X.Y.Z phù hợp. Hành động 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 điền tất cả thông tin chi tiết và đặt mốc quan trọng, hãy gửi vấn đề.
- Bot cherry-pick sẽ xử lý yêu cầu và thông báo nếu(các) cam kết đủ điều kiện để cherry-pick. Nếu các cam kết có thể chọn lọc, tức là không có xung đột hợp nhất trong khi chọn lọc cam kết, thì bot sẽ tạo một yêu cầu kéo mới. Khi yêu cầu kéo được một thành viên trong nhóm Bazel phê duyệt, các cam kết 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.
Xác định các vấn đề chặn bản phát hành và khắc phục các vấn đề được 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 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 tìm thấy.
Tạo một bản phát hành thử nghiệm mới từ nhánh phát hành khi tất cả các vấn đề chặn phát hành đã biết đều được giải quyết.
- Ứng cử viên phát hành được công bố trên bazel-discuss, nhóm Bazel sẽ giám sát các báo cáo lỗi của cộng đồng đối với ứng cử viên này.
- Nếu bạn xác định được các vấn đề mới ngăn chặn việc phát hành, 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 đề.
- Bạn không được phép thêm các tính năng mới vào nhánh phát hành sau khi tạo ứng cử viên phát hành đầu tiên; chỉ được phép 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 những lợi ích gì? Khả năng thay đổi này gây ra lỗi hồi quy là bao nhiêu?
Đẩ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 vấn đề nào khác ngăn chặn việc phát hành
- Đối với bản phát hành bản vá, hãy phát hành ít nhất hai ngày làm việc sau khi bản phát hành ứng cử viên cuối cùng được phát hành.
- Đối với các 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 ứng cử viên cuối cùng được phát hành, nhưng không sớm hơn 1 tuần sau khi bản phát hành ứng cử viên đầ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 này được thông báo trên bazel-discuss. 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 đối với bản phát hành mới.

Báo cáo lỗi hồi quy

Nếu người dùng phát hiện thấy lỗi hồi quy trong một bản phát hành Bazel mới, bản phát hành thử nghiệm 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 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 ứng cử viên phát hành thứ hai của 6.2.0, bạn có thể phân đô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 thiết để tái hiện vấn đề. Để biết thêm thông tin chi tiết, hãy xem tài liệu về tính năng phân đô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 phân đô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 nhiều phiên bản Bazel, vui lòng xem trang Khả năng tương thích của quy tắc.