ตามที่ประกาศไว้ในบล็อกโพสต์ต้นฉบับ Bazel 4.0 ขึ้นไปจะรองรับแทร็กการเผยแพร่ 2 แทร็ก ได้แก่ การเผยแพร่แบบต่อเนื่องและการเผยแพร่แบบการสนับสนุนระยะยาว (LTS) หน้านี้จะอธิบายข้อมูลล่าสุดเกี่ยวกับรูปแบบการเผยแพร่ของ Bazel
เมทริกซ์การสนับสนุน
| รุ่น LTS | ขั้นตอนการสนับสนุน | เวอร์ชันล่าสุด | สิ้นสุดการสนับสนุน |
|---|---|---|---|
| Bazel 10 | ทบเวลา | ดูหน้าการเปิดตัวแบบต่อเนื่อง | ไม่มี |
| Bazel 9 | ใช้งานอยู่ | 9.3.1 | ธ.ค. 2028 |
| Bazel 8 | การบำรุงรักษา | 8.8.2 | ธ.ค. 2027 |
| Bazel 7 | การบำรุงรักษา | 7.7.2 | ธ.ค. 2026 |
| Bazel 6 | เลิกใช้ | 6.6.0 | ธ.ค. 2025 |
| Bazel 5 | เลิกใช้ | 5.4.1 | มกราคม 2025 |
| Bazel 4 | เลิกใช้ | 4.2.4 | Jan 2024 |
คุณดู Bazel LTS ทุกรุ่นได้ในหน้ารุ่นใน GitHub ป้าย "ล่าสุด" ใน GitHub จะชี้ไปยังเวอร์ชันเชิงความหมายสูงสุดเสมอ แม้ว่าแพตช์การบำรุงรักษาสำหรับเวอร์ชันเก่าจะเผยแพร่เมื่อเร็วๆ นี้ก็ตาม
การกำหนดเวอร์ชันที่เผยแพร่
Bazel ใช้รูปแบบการกำหนดเวอร์ชันทางอรรถศาสตร์ major.minor.patch
- รุ่นหลักจะมีฟีเจอร์ที่เข้ากันไม่ได้แบบย้อนหลังกับรุ่นก่อนหน้า Bazel เวอร์ชันหลักแต่ละเวอร์ชันเป็นรุ่น LTS
- รุ่นย่อยจะมีการแก้ไขข้อบกพร่องที่เข้ากันได้แบบย้อนหลังและฟีเจอร์ที่พอร์ตย้อนหลังจากสาขาหลัก
- รุ่นแพตช์จะมีการแก้ไขข้อบกพร่องที่สำคัญ
นอกจากนี้ เวอร์ชันทดลองใช้ก่อนเปิดตัวจะระบุโดยการเพิ่มขีดกลางและคำต่อท้ายวันที่ต่อจากหมายเลขเวอร์ชันหลักถัดไป
ตัวอย่างเช่น รุ่นใหม่ของแต่ละประเภทจะส่งผลให้มีหมายเลขเวอร์ชันต่อไปนี้
- Major: 6.0.0
- Minor: 6.1.0
- แพตช์: 6.1.2
- รุ่นทดลอง: 7.0.0-pre.20230502.1
รองรับสเตจ
Bazel เวอร์ชันหลักแต่ละเวอร์ชันจะมีระยะการสนับสนุน 4 ระยะ ดังนี้
- Rolling: เวอร์ชันหลักนี้ยังอยู่ในรุ่นทดลอง โดยทีม Bazel จะเผยแพร่เวอร์ชัน Rolling จาก HEAD
- ใช้งานอยู่: เวอร์ชันหลักนี้เป็นรุ่น LTS ที่ใช้งานอยู่ในปัจจุบัน ทีม Bazel จะพอร์ตฟีเจอร์และการแก้ไขข้อบกพร่องที่สำคัญกลับไปยังเวอร์ชันย่อย
- การบำรุงรักษา: เวอร์ชันหลักนี้เป็นรุ่น LTS เก่าในโหมดการบำรุงรักษา ทีม Bazel สัญญาว่าจะพอร์ตการแก้ไขข้อบกพร่องที่สำคัญสำหรับปัญหาด้านความปลอดภัยและปัญหาความเข้ากันได้ของระบบปฏิบัติการกลับไปยังรุ่น LTS นี้เท่านั้น
- เลิกใช้งานแล้ว: ทีม Bazel ไม่ให้การสนับสนุนเวอร์ชันหลักนี้อีกต่อไป ผู้ใช้ทั้งหมดควรย้ายข้อมูลไปยัง Bazel LTS รุ่นที่ใหม่กว่า
ความถี่ในการเผยแพร่
Bazel เผยแพร่รุ่นสำหรับแทร็กการเผยแพร่ 2 แทร็กเป็นประจำ
การเผยแพร่แบบต่อเนื่อง
- การเปิดตัวแบบต่อเนื่องจะประสานงานกับการเปิดตัว Google Blaze และจะเปิดตัวจาก HEAD ทุกๆ 2 สัปดาห์โดยประมาณ ซึ่งเป็นตัวอย่างของ Bazel LTS รุ่นถัดไป
- การเปิดตัวแบบต่อเนื่องอาจทำให้เกิดการเปลี่ยนแปลงที่เข้ากันไม่ได้ เราขอแนะนำให้ใช้ Flag ที่เข้ากันไม่ได้สำหรับการเปลี่ยนแปลงที่ส่งผลกับส่วนอื่นในระบบ การเปิดตัวการเปลี่ยนแปลงที่เข้ากันไม่ได้ควรเป็นไปตามนโยบายความเข้ากันได้แบบย้อนหลัง
เวอร์ชัน LTS
- รุ่นหลัก: คาดว่าจะมีการตัดรุ่น LTS ใหม่จาก HEAD ทุกๆ 12 เดือนโดยประมาณ เมื่อมีการเปิดตัว LTS เวอร์ชันใหม่ เวอร์ชันดังกล่าวจะเข้าสู่ระยะ "ใช้งานอยู่" ทันที และ LTS เวอร์ชันก่อนหน้าจะเข้าสู่ระยะ "การบำรุงรักษา"
- เวอร์ชันย่อย: เวอร์ชันย่อยใหม่ในแทร็ก LTS ที่ใช้งานอยู่คาดว่าจะเปิดตัวทุกๆ 2 เดือน
- การเผยแพร่แพตช์: คาดว่าจะมีการเผยแพร่แพตช์เวอร์ชันใหม่สำหรับรุ่น LTS ในระยะที่ใช้งานอยู่และระยะการบำรุงรักษาตามความจำเป็นเพื่อแก้ไขข้อบกพร่องที่สำคัญ
- Bazel LTS เวอร์ชันหนึ่งๆ จะเข้าสู่ระยะเลิกใช้งานหลังจากอยู่ในระยะการบำรุงรักษาเป็นเวลา 2 ปี
สำหรับรุ่นที่วางแผนไว้ โปรดดูปัญหาเกี่ยวกับรุ่นใน GitHub
ขั้นตอนและนโยบายการเผยแพร่
สำหรับรุ่นแบบต่อเนื่อง กระบวนการจะตรงไปตรงมา โดยจะมีการสร้างรุ่นใหม่ทุกๆ 2 สัปดาห์โดยประมาณ ซึ่งสอดคล้องกับเกณฑ์พื้นฐานเดียวกันกับรุ่น Blaze ภายในของ Google เนื่องจากกำหนดการเผยแพร่ที่รวดเร็ว เราจึงไม่พอร์ตการเปลี่ยนแปลงใดๆ กลับไปยังเวอร์ชันที่เผยแพร่แบบต่อเนื่อง
สำหรับรุ่น LTS จะมีการปฏิบัติตามขั้นตอนและนโยบายด้านล่างนี้
- กำหนดคอมมิตพื้นฐานสำหรับรุ่น
- สำหรับ LTS รุ่นหลักใหม่ คอมมิตพื้นฐานคือ HEAD ของสาขาหลัก
- สำหรับรุ่นย่อยหรือรุ่นแพตช์ คอมมิตพื้นฐานคือ HEAD ของเวอร์ชันล่าสุดในปัจจุบันของรุ่น LTS เดียวกัน
- สร้างสาขาของรุ่นในชื่อ
release-<version>จากคอมมิตพื้นฐาน - Backport changes via PRs to the release branch.
- ชุมชนสามารถแนะนำคอมมิตบางรายการให้พอร์ตย้อนกลับได้โดยตอบกลับ "
@bazel-io flag" ในปัญหาหรือ PR ของ GitHub ที่เกี่ยวข้องเพื่อทำเครื่องหมายว่าเป็นตัวบล็อกการเผยแพร่ที่อาจเกิดขึ้น ทีม Bazel จะคัดแยกและตัดสินใจว่าจะพอร์ตคอมมิตย้อนกลับหรือไม่ - เฉพาะคอมมิตที่เข้ากันได้แบบย้อนหลังในสาขาหลักเท่านั้นที่สามารถพอร์ตย้อนหลังได้ การเปลี่ยนแปลงเล็กน้อยเพิ่มเติมเพื่อแก้ไขความขัดแย้งในการผสานนั้นยอมรับได้
- ชุมชนสามารถแนะนำคอมมิตบางรายการให้พอร์ตย้อนกลับได้โดยตอบกลับ "
แบ็กพอร์ตการเปลี่ยนแปลงโดยใช้ปัญหาคำขอ Cherry-Pick สำหรับผู้ดูแล Bazel
ผู้ดูแล Bazel สามารถขอเลือกคอมมิตที่เฉพาะเจาะจงไปยังสาขาการเผยแพร่ได้ กระบวนการนี้เริ่มต้นด้วยการสร้างคำขอ Cherry-Pick ใน GitHub โดยทำดังนี้
- เปิดคำขอเลือกเชอร์รี่
- กรอกรายละเอียดคำขอ
- ชื่อ: ระบุชื่อคำขอที่กระชับและสื่อความหมาย
- รหัสคอมมิต: ป้อนรหัสของคอมมิตที่ต้องการเลือกเฉพาะบางส่วน หากมีคอมมิตหลายรายการ ให้คั่นด้วยคอมมา
- หมวดหมู่: ระบุหมวดหมู่ของคำขอ
- ผู้ตรวจสอบ: สำหรับผู้ตรวจสอบหลายคน ให้คั่นรหัส GitHub ด้วยคอมมา
- กำหนดเป้าหมาย
- ค้นหาส่วน "เป้าหมาย" แล้วคลิกการตั้งค่า
- เลือกตัวบล็อกรุ่น X.Y.Z ที่เหมาะสม การดำเนินการนี้จะทริกเกอร์บ็อต Cherry-Pick ให้ประมวลผลคำขอสำหรับสาขา "release-X.Y.Z"
- ส่งปัญหา
- เมื่อกรอกรายละเอียดทั้งหมดและตั้งค่าเหตุการณ์สำคัญแล้ว ให้ส่งปัญหา
บ็อต Cherry-Pick จะประมวลผลคำขอและแจ้งให้ทราบหากคอมมิตมีสิทธิ์ใช้ Cherry-Pick หากคอมมิตเป็นแบบ Cherry-Pick ได้ ซึ่งหมายความว่าไม่มีความขัดแย้งในการผสานขณะเลือกคอมมิต บ็อตจะสร้าง Pull Request ใหม่ เมื่อ Pull Request ได้รับอนุมัติจากสมาชิกทีม Bazel ระบบจะเลือกคอมมิตและผสานรวมกับสาขาการเผยแพร่ ดูตัวอย่างภาพของคำขอ Cherry-Pick ที่เสร็จสมบูรณ์ได้จากตัวอย่างนี้
ระบุตัวบล็อกการเผยแพร่และแก้ไขปัญหาที่พบในสาขาการเผยแพร่
- สาขาของรุ่นจะได้รับการทดสอบด้วยชุดโปรแกรมทดสอบเดียวกันในpostsubmitและไปป์ไลน์การทดสอบดาวน์สตรีมใน Bazel CI ทีม Bazel จะตรวจสอบผลการทดสอบของสาขาการเผยแพร่และแก้ไขปัญหาการถดถอยที่พบ
สร้างรุ่นที่อาจได้รับการเผยแพร่ใหม่จากสาขาของรุ่นเมื่อแก้ไขตัวบล็อกรุ่นที่ทราบทั้งหมดแล้ว
- ระบบจะประกาศรุ่นที่อาจได้รับการเผยแพร่ใน bazel-discuss โดยทีม Bazel จะตรวจสอบรายงานข้อบกพร่องของชุมชนสำหรับรุ่นที่อาจได้รับการเผยแพร่
- หากพบปัญหาที่บล็อกการเผยแพร่ใหม่ ให้กลับไปที่ขั้นตอนสุดท้ายและสร้างรุ่นที่อาจได้รับการเผยแพร่ใหม่หลังจากแก้ไขปัญหาทั้งหมดแล้ว
- ไม่อนุญาตให้เพิ่มฟีเจอร์ใหม่ลงในสาขาการเผยแพร่หลังจากสร้างรุ่นที่อาจได้รับการเผยแพร่รุ่นแรกแล้ว โดยจะจำกัดการเลือกเฉพาะการแก้ไขที่สำคัญเท่านั้น หากจำเป็นต้องเลือกแบบเจาะจง ผู้ขอต้องตอบคำถามต่อไปนี้ เหตุใดการเปลี่ยนแปลงนี้จึงสำคัญ และมีประโยชน์อย่างไร การเปลี่ยนแปลงนี้มีแนวโน้มที่จะทำให้เกิดการถดถอยมากน้อยเพียงใด
พุชรุ่นที่อาจได้รับการเผยแพร่เป็นรุ่นอย่างเป็นทางการหากไม่พบตัวบล็อกการเผยแพร่เพิ่มเติม
- สำหรับแพตช์ ให้พุชรุ่นอย่างน้อย 2 วันทำการหลังจากที่รุ่นที่อาจได้รับการเผยแพร่ล่าสุดเปิดตัว
- สำหรับการเผยแพร่เวอร์ชันหลักและเวอร์ชันย่อย ให้พุชการเผยแพร่ 2 วันทำการหลังจากที่เผยแพร่เวอร์ชันที่อาจได้รับการเผยแพร่ล่าสุด แต่ต้องไม่เร็วกว่า 1 สัปดาห์หลังจากที่เผยแพร่เวอร์ชันที่อาจได้รับการเผยแพร่เวอร์ชันแรก
- โดยจะพุชเวอร์ชันใหม่ในวันที่วันถัดไปเป็นวันทำการเท่านั้น
- เราจะประกาศการเผยแพร่ใน bazel-discuss โดยทีม Bazel จะตรวจสอบและแก้ไขรายงานข้อบกพร่องจากชุมชนสำหรับรุ่นใหม่
รายงานการถดถอย
หากผู้ใช้พบการถดถอยใน Bazel รุ่นใหม่ รุ่นที่อาจได้รับการเผยแพร่ หรือแม้แต่ Bazel ที่ HEAD โปรดรายงานข้อบกพร่องใน GitHub คุณสามารถใช้ Bazelisk เพื่อแยกคอมมิตที่เป็นสาเหตุและรวมข้อมูลนี้ไว้ในรายงานข้อบกพร่อง
ตัวอย่างเช่น หากบิลด์สำเร็จด้วย Bazel 6.1.0 แต่ไม่สำเร็จด้วยรุ่นที่อาจได้รับการเผยแพร่รุ่นที่ 2 ของ 6.2.0 คุณสามารถทำการแบ่งครึ่งผ่าน
bazelisk --bisect=6.1.0..release-6.2.0rc2 build //foo:bar
คุณสามารถตั้งค่าตัวแปรสภาพแวดล้อม BAZELISK_SHUTDOWN หรือ BAZELISK_CLEAN เพื่อเรียกใช้คำสั่ง bazel ที่เกี่ยวข้องเพื่อรีเซ็ตสถานะการสร้างได้ หากจำเป็นต้องจำลองปัญหาขึ้นมาอีกครั้ง ดูรายละเอียดเพิ่มเติมได้ในเอกสารประกอบเกี่ยวกับฟีเจอร์ Bisect ของ Bazelisk
อย่าลืมอัปเกรด Bazelisk เป็นเวอร์ชันล่าสุดเพื่อใช้ฟีเจอร์ Bisect
ความเข้ากันได้ของกฎ
หากคุณเป็นผู้เขียนกฎและต้องการรักษาความเข้ากันได้กับ Bazel เวอร์ชันต่างๆ โปรดดูหน้าความเข้ากันได้ของกฎ