รุ่นที่เผยแพร่

ตามที่ประกาศไว้ใน บล็อกโพสต์ ต้นฉบับ Bazel เวอร์ชัน 4.0 ขึ้นไปรองรับแทร็กการเผยแพร่ 2 รายการ ได้แก่ การเผยแพร่แบบต่อเนื่อง และการเผยแพร่การสนับสนุนระยะยาว (LTS) หน้านี้ครอบคลุมข้อมูลล่าสุด เกี่ยวกับโมเดลการเผยแพร่ของ Bazel

เมทริกซ์การสนับสนุน

การเผยแพร่ LTS ระยะการสนับสนุน เวอร์ชันล่าสุด สิ้นสุดการสนับสนุน
Bazel 8 ต่อเนื่อง ดูหน้าการเผยแพร่แบบต่อเนื่อง ไม่มี
Bazel 7 ใช้งานอยู่ 7.4.1 ธ.ค. 2026
Bazel 6 การบำรุงรักษา 6.5.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 หลัก
  • A การเผยแพร่เวอร์ชันแพตช์มีการแก้ไขข้อบกพร่องที่สำคัญ

นอกจากนี้ ระบบจะระบุเวอร์ชันก่อนเปิดตัวโดยการเพิ่มยัติภังค์และคำต่อท้ายวันที่ลงในหมายเลขเวอร์ชันหลักถัดไป

ตัวอย่างเช่น การเผยแพร่ใหม่ของแต่ละประเภทจะทำให้เกิดหมายเลขเวอร์ชันต่อไปนี้

  • หลัก: 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 เราจะทำตามขั้นตอนและนโยบายด้านล่าง

  1. กำหนดคอมมิตพื้นฐานสำหรับการเผยแพร่
    • สำหรับการเผยแพร่ LTS เวอร์ชันหลักใหม่ คอมมิตพื้นฐานคือ HEAD ของ Branch หลัก
    • สำหรับการเผยแพร่เวอร์ชันย่อยหรือแพตช์ คอมมิตพื้นฐานคือ HEAD ของ เวอร์ชันล่าสุดปัจจุบันของการเผยแพร่ LTS เดียวกัน
  2. สร้าง Branch การเผยแพร่ในชื่อ release-<version> จากคอมมิตพื้นฐาน
  3. ย้ายการเปลี่ยนแปลงผ่าน PR ไปยัง Branch การเผยแพร่
    • ชุมชนสามารถแนะนำคอมมิตบางรายการที่จะย้ายได้โดยตอบกลับ "@bazel-io flag" ในปัญหาหรือ PR ที่เกี่ยวข้องใน GitHub เพื่อทำเครื่องหมายคอมมิตเหล่านั้นเป็นตัวบล็อกการเผยแพร่ที่อาจเกิดขึ้น ทีม Bazel จะจัดลำดับความสำคัญและตัดสินใจว่าจะ ย้ายคอมมิตหรือไม่
    • เฉพาะคอมมิตที่เข้ากันได้กับเวอร์ชันก่อนหน้าใน Branch หลักเท่านั้นที่จะย้ายได้ และเราอนุญาตให้มีการเปลี่ยนแปลงเล็กน้อยเพิ่มเติมเพื่อแก้ไขข้อขัดแย้งในการผสาน
  4. ย้ายการเปลี่ยนแปลงโดยใช้ปัญหาคำขอ Cherry-Pick สำหรับผู้ดูแล Bazel

    • ผู้ดูแล Bazel สามารถขอ Cherry-Pick คอมมิตที่เฉพาะเจาะจง ไปยัง Branch การเผยแพร่ได้ กระบวนการนี้เริ่มต้นด้วยการสร้างคำขอ Cherry-Pick ใน GitHub วิธีดำเนินการมีดังนี้

      1. เปิดคำขอ Cherry-Pick
      2. กรอกรายละเอียดคำขอ
        • ชื่อ: ตั้งชื่อคำขอให้กระชับและสื่อความหมาย
        • รหัสคอมมิต: ป้อนรหัสของคอมมิตที่ต้องการ Cherry-Pick หากมีคอมมิตหลายรายการ ให้คั่น ด้วยคอมมา
        • หมวดหมู่: ระบุหมวดหมู่ของคำขอ
        • ผู้ตรวจสอบ: หากมีผู้ตรวจสอบหลายคน ให้คั่นรหัส GitHub ของผู้ตรวจสอบแต่ละคนด้วยคอมมา
      3. กำหนดเป้าหมาย
        • ค้นหาส่วน "เป้าหมาย" แล้วคลิกการตั้งค่า
        • เลือกตัวบล็อกการเผยแพร่ X.Y.Z ที่เหมาะสม การดำเนินการนี้ จะทริกเกอร์บ็อต Cherry-Pick ให้ประมวลผลคำขอของคุณ สำหรับ Branch "release-X.Y.Z"
      4. ส่งปัญหา
        • เมื่อกรอกรายละเอียดทั้งหมดและกำหนดเป้าหมายแล้ว ให้ส่งปัญหา
    • บ็อต Cherry-Pick จะประมวลผลคำขอและแจ้งให้ทราบ หากคอมมิตมีสิทธิ์ Cherry-Pick หาก คอมมิต Cherry-Pick ได้ ซึ่งหมายความว่าจะไม่มี ข้อขัดแย้งในการผสานขณะ Cherry-Pick คอมมิต แล้ว บ็อตจะสร้างคำขอ Pull ใหม่ เมื่อสมาชิกทีม Bazel อนุมัติคำขอ Pull แล้ว ระบบจะ Cherry-Pick คอมมิต และผสานไปยัง Branch การเผยแพร่ ดูตัวอย่างภาพคำขอ Cherry-Pick ที่เสร็จสมบูรณ์ได้ที่ ตัวอย่าง นี้ .

  5. ระบุตัวบล็อกการเผยแพร่และแก้ไขปัญหาที่พบใน Branch การเผยแพร่

    • ระบบจะทดสอบ Branch การเผยแพร่ด้วยชุดทดสอบเดียวกันใน postsubmit และ ไปป์ไลน์การทดสอบดาวน์สตรีม ใน Bazel CI ทีม Bazel จะตรวจสอบผลการทดสอบของ Branch การเผยแพร่ และแก้ไขการถดถอยที่พบ
  6. สร้างรุ่นที่อาจได้รับการเผยแพร่ใหม่จาก Branch การเผยแพร่เมื่อแก้ไขตัวบล็อกการเผยแพร่ที่ทราบทั้งหมดแล้ว

    • เราจะประกาศรุ่นที่อาจได้รับการเผยแพร่ใน bazel-discuss, และทีม Bazel จะตรวจสอบรายงานข้อบกพร่องของชุมชนสำหรับรุ่นดังกล่าว
    • หากพบตัวบล็อกการเผยแพร่ใหม่ ให้กลับไปที่ขั้นตอนสุดท้ายและ สร้างรุ่นที่อาจได้รับการเผยแพร่ใหม่หลังจากแก้ไขปัญหาทั้งหมดแล้ว
    • เราไม่อนุญาตให้เพิ่มฟีเจอร์ใหม่ลงใน Branch การเผยแพร่หลังจากสร้างรุ่นที่อาจได้รับการเผยแพร่รุ่นแรกแล้ว และการ Cherry-Pick จะจำกัดเฉพาะการแก้ไขที่สำคัญเท่านั้น หากจำเป็นต้อง Cherry-Pick ผู้ขอจะต้องตอบคำถามต่อไปนี้ การเปลี่ยนแปลงนี้สำคัญอย่างไร และมีประโยชน์อย่างไร การเปลี่ยนแปลงนี้มีแนวโน้มที่จะทำให้เกิด การถดถอยมากน้อยเพียงใด
  7. เผยแพร่รุ่นที่อาจได้รับการเผยแพร่เป็นรุ่นอย่างเป็นทางการหากไม่พบตัวบล็อกการเผยแพร่เพิ่มเติม

    • สำหรับการเผยแพร่แพตช์ ให้เผยแพร่หลังจาก รุ่นที่อาจได้รับการเผยแพร่รุ่นสุดท้ายออกไปแล้วอย่างน้อย 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 เวอร์ชันต่างๆ โปรดดูหน้าความเข้ากันได้ของ กฎ