ตามที่ประกาศไว้ใน บล็อกโพสต์ ต้นฉบับ Bazel 4.0 ขึ้นไปรองรับแทร็กการเผยแพร่ 2 รายการ ได้แก่ การเผยแพร่แบบต่อเนื่อง และการเผยแพร่แบบการสนับสนุนระยะยาว (LTS) หน้านี้ครอบคลุมข้อมูลล่าสุดเกี่ยวกับโมเดลการเผยแพร่ของ Bazel
เมทริกซ์การสนับสนุน
| การเผยแพร่แบบ LTS | ระยะการสนับสนุน | เวอร์ชันล่าสุด | สิ้นสุดการสนับสนุน |
|---|---|---|---|
| Bazel 10 | ต่อเนื่อง | ดูหน้าการเผยแพร่แบบต่อเนื่อง | ไม่มี |
| Bazel 9 | ใช้งานอยู่ | 9.1.0 | ธ.ค. 2028 |
| Bazel 8 | การบำรุงรักษา | 8.6.0 | ธ.ค. 2027 |
| Bazel 7 | การบำรุงรักษา | 7.7.1 | ธ.ค. 2026 |
| Bazel 6 | เลิกใช้ | 6.6.0 | ธ.ค. 2025 |
| Bazel 5 | เลิกใช้ | 5.4.1 | ม.ค. 2025 |
| Bazel 4 | เลิกใช้ | 4.2.4 | ม.ค. 2024 |
คุณดูการเผยแพร่แบบ LTS ของ Bazel ทั้งหมดได้ใน หน้า การเผยแพร่ใน GitHub
การกำหนดเวอร์ชันการเผยแพร่
Bazel ใช้รูปแบบการกำหนดเวอร์ชันเชิงความหมาย major.minor.patch Semantic Versioning
- การเผยแพร่เวอร์ชันหลัก มีฟีเจอร์ที่เข้ากันไม่ได้กับเวอร์ชันก่อนหน้า Bazel เวอร์ชันหลักแต่ละเวอร์ชันเป็นการเผยแพร่แบบ LTS
- การเผยแพร่เวอร์ชันย่อย มีการแก้ไขข้อบกพร่องและฟีเจอร์ที่เข้ากันได้กับเวอร์ชันก่อนหน้าซึ่งย้ายมาจาก Branch หลัก
- การเผยแพร่เวอร์ชันแพตช์ มีการแก้ไขข้อบกพร่องที่สำคัญ
นอกจากนี้ ระบบจะระบุเวอร์ชันก่อนเปิดตัวโดยการต่อท้ายเครื่องหมายยัติภังค์และคำต่อท้ายวันที่ด้วยหมายเลขเวอร์ชันหลักถัดไป
ตัวอย่างเช่น การเผยแพร่เวอร์ชันใหม่ของแต่ละประเภทจะส่งผลให้หมายเลขเวอร์ชันเป็นดังนี้
- หลัก: 6.0.0
- ย่อย: 6.1.0
- แพตช์: 6.1.2
- ก่อนเปิดตัว: 7.0.0-pre.20230502.1
ระยะการสนับสนุน
Bazel เวอร์ชันหลักแต่ละเวอร์ชันมีระยะการสนับสนุน 4 ระยะ ดังนี้
- ต่อเนื่อง: เวอร์ชันหลักนี้ยังอยู่ในระยะก่อนเปิดตัว ทีม Bazel จะเผยแพร่แบบต่อเนื่องจาก HEAD
- ใช้งานอยู่: เวอร์ชันหลักนี้เป็นการเผยแพร่แบบ LTS ที่ใช้งานอยู่ในปัจจุบัน ทีม Bazel จะย้ายฟีเจอร์ที่สำคัญและการแก้ไขข้อบกพร่องไปยังการเผยแพร่เวอร์ชันย่อย
- การบำรุงรักษา: เวอร์ชันหลักนี้เป็นการเผยแพร่แบบ LTS เก่าที่อยู่ในโหมดการบำรุงรักษา ทีม Bazel สัญญาว่าจะย้ายเฉพาะการแก้ไขข้อบกพร่องที่สำคัญสำหรับปัญหาด้านความปลอดภัยและปัญหาความเข้ากันได้ของระบบปฏิบัติการไปยังการเผยแพร่แบบ LTS นี้
- เลิกใช้: ทีม Bazel ไม่ได้ให้การสนับสนุนเวอร์ชันหลัก นี้อีกต่อไป ผู้ใช้ทุกคนควรย้ายข้อมูลไปยังการเผยแพร่แบบ LTS ของ Bazel เวอร์ชันใหม่กว่า
ความถี่ในการเผยแพร่
Bazel เผยแพร่การเผยแพร่สำหรับแทร็กการเผยแพร่ 2 รายการเป็นประจำ
การเผยแพร่แบบต่อเนื่อง
- การเผยแพร่แบบต่อเนื่องจะประสานงานกับการเผยแพร่ Google Blaze และเผยแพร่จาก HEAD ทุกๆ 2 สัปดาห์โดยประมาณ ซึ่งเป็นการแสดงตัวอย่างการเผยแพร่แบบ LTS ของ Bazel ครั้งถัดไป
- การเผยแพร่แบบต่อเนื่องอาจมีการเปลี่ยนแปลงที่ไม่เข้ากัน เราขอแนะนำให้ใช้แฟล็กที่ไม่เข้ากันสำหรับ การเปลี่ยนแปลงที่สำคัญซึ่งทำให้เกิดการหยุดทำงาน การเปิดตัวการเปลี่ยนแปลงที่ไม่เข้ากัน ควรเป็นไปตามนโยบายความเข้ากันได้กับเวอร์ชันก่อนหน้า
การเผยแพร่แบบ LTS
- การเผยแพร่เวอร์ชันหลัก: คาดว่าจะมีการตัดการเผยแพร่แบบ LTS ใหม่จาก HEAD ทุกๆ 12 เดือน โดยประมาณ เมื่อมีการเผยแพร่แบบ LTS ใหม่แล้ว การเผยแพร่แบบ LTS ก่อนหน้าจะเข้าสู่ระยะการบำรุงรักษาทันที
- การเผยแพร่เวอร์ชันย่อย: คาดว่าจะมีการเผยแพร่เวอร์ชันย่อยใหม่ในแทร็ก LTS ที่ใช้งานอยู่ทุกๆ 2 เดือน
- การเผยแพร่เวอร์ชันแพตช์: คาดว่าจะมีการเผยแพร่เวอร์ชันแพตช์ใหม่สำหรับการเผยแพร่แบบ LTS ในระยะใช้งานอยู่และ ระยะการบำรุงรักษาตามความต้องการสำหรับการแก้ไขข้อบกพร่องที่สำคัญ
- การเผยแพร่แบบ LTS ของ Bazel จะเข้าสู่ระยะเลิกใช้หลังจากอยู่ในระยะการบำรุงรักษาเป็นเวลา 2 ปี
สำหรับการเผยแพร่ที่วางแผนไว้ โปรดดูปัญหาการเผยแพร่ใน Github
ขั้นตอนและนโยบายการเผยแพร่
สำหรับขั้นตอนการเผยแพร่แบบต่อเนื่องนั้นตรงไปตรงมา โดยจะมีการสร้างการเผยแพร่ใหม่ทุกๆ 2 สัปดาห์โดยประมาณ ซึ่งสอดคล้องกับบรรทัดฐานเดียวกันกับการเผยแพร่ Blaze ภายในของ Google เนื่องจากกำหนดการเผยแพร่อย่างรวดเร็ว เราจึงไม่ย้ายการเปลี่ยนแปลงใดๆ ไปยังการเผยแพร่แบบต่อเนื่อง
สำหรับการเผยแพร่แบบ LTS เราจะทำตามขั้นตอนและนโยบายด้านล่าง
- กำหนดคอมมิตบรรทัดฐานสำหรับการเผยแพร่
- สำหรับการเผยแพร่แบบ LTS เวอร์ชันหลักใหม่ คอมมิตบรรทัดฐานคือ HEAD ของ Branch หลัก
- สำหรับการเผยแพร่เวอร์ชันย่อยหรือเวอร์ชันแพตช์ คอมมิตบรรทัดฐานคือ HEAD ของเวอร์ชันล่าสุดปัจจุบันของการเผยแพร่แบบ LTS เดียวกัน
- สร้าง Branch การเผยแพร่ในชื่อ
release-<version>จากคอมมิตบรรทัดฐาน - ย้ายการเปลี่ยนแปลงผ่าน PR ไปยัง Branch การเผยแพร่
- ชุมชนสามารถแนะนำคอมมิตบางรายการที่จะย้ายได้โดยตอบกลับ "
@bazel-io flag" ในปัญหาหรือ PR ที่เกี่ยวข้องใน GitHub เพื่อทำเครื่องหมายคอมมิตเหล่านั้นเป็นตัวบล็อกการเผยแพร่ที่อาจเกิดขึ้น ทีม Bazel จะจัดลำดับความสำคัญและตัดสินใจว่าจะย้ายคอมมิตหรือไม่ - เฉพาะคอมมิตที่เข้ากันได้กับเวอร์ชันก่อนหน้าใน Branch หลักเท่านั้นที่จะย้ายได้ และอนุญาตให้มีการเปลี่ยนแปลงเล็กน้อยเพิ่มเติมเพื่อแก้ไขข้อขัดแย้งในการผสาน
- ชุมชนสามารถแนะนำคอมมิตบางรายการที่จะย้ายได้โดยตอบกลับ "
ย้ายการเปลี่ยนแปลงโดยใช้ปัญหาคำขอ Cherry-Pick สำหรับผู้ดูแล Bazel
ผู้ดูแล Bazel สามารถขอเลือกใช้คอมมิตที่เฉพาะเจาะจงไปยัง Branch การเผยแพร่ได้ กระบวนการนี้จะเริ่มต้นโดยการสร้างคำขอ Cherry-Pick ใน GitHub วิธีดำเนินการมีดังนี้
- เปิดคำขอ เลือกใช้
- กรอกรายละเอียดคำขอ
- ชื่อ: ตั้งชื่อคำขอให้กระชับและสื่อความหมาย
- รหัสคอมมิต: ป้อนรหัสของคอมมิตที่ต้องการเลือกใช้ หากมีคอมมิตหลายรายการ ให้คั่นคอมมิตเหล่านั้นด้วยคอมมา
- หมวดหมู่: ระบุหมวดหมู่ของคำขอ
- ผู้ตรวจสอบ: หากมีผู้ตรวจสอบหลายคน ให้คั่นรหัส GitHub ของผู้ตรวจสอบแต่ละคนด้วยคอมมา
- กำหนดเป้าหมาย
- ค้นหาส่วน "เป้าหมาย" แล้วคลิกการตั้งค่า
- เลือกตัวบล็อกการเผยแพร่ X.Y.Z ที่เหมาะสม การดำเนินการนี้จะทริกเกอร์บ็อตเลือกใช้ให้ประมวลผลคำขอของคุณสำหรับ Branch "release-X.Y.Z"
- ส่งปัญหา
- เมื่อกรอกรายละเอียดทั้งหมดและกำหนดเป้าหมายแล้ว ให้ส่งปัญหา
บ็อตเลือกใช้จะประมวลผลคำขอและแจ้งให้ทราบหากคอมมิตมีสิทธิ์เลือกใช้ หากคอมมิต Cherry-Pick ได้ ซึ่งหมายความว่าจะไม่มีข้อขัดแย้งในการผสานขณะ Cherry-Pick คอมมิต บ็อตจะสร้าง Pull Request ใหม่ เมื่อสมาชิกทีม Bazel อนุมัติคำขอ Pull แล้ว ระบบจะ Cherry-Pick คอมมิตและผสานคอมมิตเหล่านั้นไปยัง Branch การเผยแพร่ ดูตัวอย่างภาพคำขอเลือกใช้ Cherry-Pick ที่เสร็จสมบูรณ์ได้ที่ ตัวอย่าง นี้ .
ระบุตัวบล็อกการเผยแพร่และแก้ไขปัญหาที่พบใน Branch การเผยแพร่
- ระบบจะทดสอบ Branch การเผยแพร่ด้วยชุดการทดสอบเดียวกันใน postsubmit และ ไปป์ไลน์การทดสอบดาวน์สตรีม ใน Bazel CI ทีม Bazel จะตรวจสอบผลการทดสอบของ Branch การเผยแพร่และแก้ไขการถดถอยที่พบ
สร้างรุ่นที่อาจได้รับการเผยแพร่ใหม่จาก Branch การเผยแพร่เมื่อแก้ไขตัวบล็อกการเผยแพร่ที่ทราบทั้งหมดแล้ว
- เราจะประกาศรุ่นที่อาจได้รับการเผยแพร่ใน bazel-discuss, และทีม Bazel จะตรวจสอบรายงานข้อบกพร่องของชุมชนสำหรับรุ่นที่อาจได้รับการเผยแพร่
- หากพบตัวบล็อกการเผยแพร่ใหม่ ให้กลับไปที่ขั้นตอนสุดท้ายและสร้างรุ่นที่อาจได้รับการเผยแพร่ใหม่หลังจากแก้ไขปัญหาทั้งหมดแล้ว
- ไม่อนุญาตให้เพิ่มฟีเจอร์ใหม่ลงใน Branch การเผยแพร่หลังจากสร้างรุ่นที่อาจได้รับการเผยแพร่รุ่นแรกแล้ว และการ Cherry-Pick จะจำกัดเฉพาะการแก้ไขที่สำคัญเท่านั้น หากจำเป็นต้องเลือกใช้ ผู้ขอจะต้องตอบคำถามต่อไปนี้ การเปลี่ยนแปลงนี้สำคัญอย่างไร และการเปลี่ยนแปลงนี้มีประโยชน์อย่างไร การเปลี่ยนแปลงนี้มีแนวโน้มที่จะทำให้เกิดการถดถอยมากน้อยเพียงใด
เผยแพร่รุ่นที่อาจได้รับการเผยแพร่เป็นรุ่นอย่างเป็นทางการหากไม่พบตัวบล็อกการเผยแพร่เพิ่มเติม
- สำหรับการเผยแพร่เวอร์ชันแพตช์ ให้เผยแพร่หลังจากรุ่นที่อาจได้รับการเผยแพร่รุ่นสุดท้ายออกแล้วอย่างน้อย 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 ที่เกี่ยวข้องเพื่อรีเซ็ตสถานะการสร้างหากจำเป็นต้องสร้างปัญหาซ้ำ ดูรายละเอียดเพิ่มเติมได้ในเอกสารประกอบเกี่ยวกับฟีเจอร์การแบ่งของ Bazelisk
อย่าลืมอัปเกรด Bazelisk เป็นเวอร์ชันล่าสุดเพื่อใช้ฟีเจอร์การแบ่ง
ความเข้ากันได้ของกฎ
หากคุณเป็นผู้เขียนกฎและต้องการรักษาความเข้ากันได้กับ Bazel เวอร์ชันต่างๆ โปรดดูหน้าความเข้ากันได้ของ กฎ