रिलीज़ मॉडल

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

ओरिजनल ब्लॉग पोस्ट में बताया गया था कि Bazel 4.0 और इसके बाद के वर्शन, रिलीज़ के दो ट्रैक के साथ काम करते हैं: रोलिंग रिलीज़ और लंबे समय तक सहायता (एलटीएस) रिलीज़. इस पेज पर, Bazel के रिलीज़ मॉडल के बारे में नई जानकारी दी गई है.

सहायता मैट्रिक

एलटीएस रिलीज़ सहायता का चरण सबसे नया वर्शन सहायता बंद होना
Bazel 8 लगातार रोलिंग रिलीज़ पेज देखना लागू नहीं
Bazel 7 चालू है 7.4.0 दिसंबर 2026
बेज़ल 6 रखरखाव 6.5.0 दिसंबर 2025
Bazel 5 रखरखाव 5.4.1 जनवरी 2025
Bazel 4 बहिष्कृत 4.2.4 जनवरी 2024

सभी Basel एलटीएस रिलीज़, GitHub पर रिलीज़ पेज पर मिल सकती हैं.

रिलीज़ के लिए वर्शन

Bazel, major.minor.patch सिमेंटिक वर्शनिंग स्कीम का इस्तेमाल करता है.

  • मुख्य रिलीज़ में ऐसी सुविधाएं होती हैं जो पिछली रिलीज़ के साथ काम नहीं करती हैं. बेज़ल का हर मेजर वर्शन, एलटीएस रिलीज़ है.
  • किसी माइनर रिलीज़ में, पुराने सिस्टम के साथ काम करने वाली गड़बड़ियां ठीक की गई होती हैं. साथ ही, इसमें ऐसी सुविधाएं शामिल होती हैं जिन्हें मुख्य ब्रांच से बैक-पोर्ट किया जाता है.
  • पैच रिलीज़ में, गड़बड़ियों को ठीक करने के लिए अहम अपडेट शामिल होते हैं.

इसके अलावा, रिलीज़ से पहले वाले वर्शन के लिए अगले मेजर वर्शन नंबर में एक हाइफ़न और तारीख का सफ़िक्स जोड़कर दिखाया जाता है.

उदाहरण के लिए, हर टाइप की नई रिलीज़ से ये वर्शन नंबर मिलेंगे:

  • मेजर: 6.0.0
  • कम: 6.1.0
  • पैच: 6.1.2
  • रिलीज़ से पहले का वर्शन: 7.0.0-pre.20230502.1

सहायता के चरण

हर मुख्य Basel वर्शन के लिए, सहायता के चार चरण हैं:

  • रोलिंग: यह मुख्य वर्शन अब भी रिलीज़ से पहले के स्टेज में है. Bazel टीम, HEAD से रोलिंग रिलीज़ पब्लिश करती है.
  • चालू: यह मेजर वर्शन, चालू एलटीएस रिलीज़ है. Bazel टीम, अपनी छोटी रिलीज़ में ज़रूरी सुविधाओं और गड़बड़ी ठीक करने की सुविधाओं को बैकपोर्ट करती है.
  • मेंटेनेंस: यह मेजर वर्शन, रखरखाव मोड में मौजूद LTS की पुरानी रिलीज़ है. Bazel टीम ने सिर्फ़ सुरक्षा से जुड़ी समस्याओं और ओएस के साथ काम करने से जुड़ी समस्याओं के लिए, इस LTS रिलीज़ में गड़बड़ी ठीक करने के लिए बैकपोर्ट करने का वादा किया है.
  • अब काम नहीं करता: Bazel की टीम अब इस मुख्य वर्शन के लिए सहायता नहीं देती. सभी उपयोगकर्ताओं को Bazel के नए एलटीएस रिलीज़ पर माइग्रेट करना चाहिए.

रिलीज़ की फ़्रीक्वेंसी

Bazel, दो रिलीज़ ट्रैक के लिए नियमित तौर पर रिलीज़ पब्लिश करता है.

रोलिंग रिलीज़

  • रोलिंग रिलीज़, Google Blaze रिलीज़ के साथ मिलकर काम करती हैं. ये रिलीज़, HEAD से हर दो हफ़्ते में होती हैं. यह अगली Babel LTS रिलीज़ का पूर्वावलोकन है.
  • रोलिंग रिलीज़, काम न करने वाले बदलावों को शिप कर सकती हैं. हमारा सुझाव है कि बड़े बदलावों के लिए, 'काम नहीं करता' फ़्लैग का इस्तेमाल करें. साथ ही, 'काम नहीं करता' फ़्लैग वाले बदलावों को रोल आउट करते समय, पुराने सिस्टम के साथ काम करने की सुविधा से जुड़ी हमारी नीति का पालन करें.

एलटीएस रिलीज़

  • मुख्य रिलीज़: करीब हर 12 महीने में, नई एलटीएस रिलीज़ को HEAD से काटा जाने की उम्मीद है. नई एलटीएस रिलीज़ के रिलीज़ होने के बाद, वह तुरंत चालू होने वाले चरण में चली जाती है. साथ ही, पिछली एलटीएस रिलीज़, रखरखाव के चरण में चली जाती है.
  • मामूली रिलीज़: ऐक्टिव LTS ट्रैक पर, हर दो महीने में एक बार नए मामूली वर्शन रिलीज़ किए जाते हैं.
  • पैच रिलीज़: ऐक्टिव और रखरखाव के चरणों में, LTS रिलीज़ के लिए नए पैच वर्शन, मांग पर रिलीज़ किए जा सकते हैं. ऐसा, गड़बड़ी को ठीक करने के लिए किया जाता है.
  • Bazel LTS रिलीज़, दो साल तक रखरखाव के चरण में रहने के बाद, 'इस्तेमाल नहीं किया जा सकता' चरण में आ जाती है.

तय की गई रिलीज़ के बारे में जानने के लिए, कृपया GitHub पर हमारी रिलीज़ से जुड़ी समस्याएं देखें.

रिलीज़ करने की प्रक्रिया और नीतियां

रोलिंग रिलीज़ के लिए यह प्रोसेस आसान है: करीब हर दो हफ़्ते में एक नई रिलीज़ बनाई जाती है और यह Google की इंटरनल ब्लेज़ रिलीज़ जैसी बेसलाइन के साथ अलाइन होती है. रिलीज़ के शेड्यूल में तेज़ी की वजह से, हम रोलिंग रिलीज़ में कोई बदलाव नहीं करते.

LTS रिलीज़ के लिए, यहां दी गई प्रोसेस और नीतियों का पालन किया जाता है:

  1. रिलीज़ के लिए बेसलाइन तय तय करें.
    • नई बड़ी एलटीएस रिलीज़ के लिए, बेसलाइन कमिटी मुख्य ब्रांच का हेड है.
    • किसी मामूली या पैच रिलीज़ के लिए, बेसलाइन कमिट उसी LTS रिलीज़ के मौजूदा सबसे नए वर्शन का HEAD होता है.
  2. बेसलाइन कमिट से, release-<version> के नाम से रिलीज़ ब्रैंच बनाएं.
  3. रिलीज़ शाखा में, पीआर के ज़रिए बदलावों को बैकपोर्ट करें.
    • समुदाय ने GitHub से जुड़ी समस्याओं पर "@bazel-io flag" या पीआर की मदद से, उन्हें बैक-पोर्ट करने का सुझाव दिया है. ऐसा करके उन्हें संभावित रिलीज़ ब्लॉकर के तौर पर मार्क किया जा सकता है. बेज़ल टीम उन्हें प्राथमिकता के साथ प्राथमिकता देती है और फ़ैसला लेती है कि उन कमिट को बैक-पोर्ट करना है या नहीं.
    • मुख्य शाखा पर मौजूद, पुराने सिस्टम के साथ काम करने वाले कमिट ही बैक-पोर्ट किए जा सकते हैं. हालांकि, मर्ज से जुड़ी समस्याओं को हल करने के लिए, कुछ छोटे बदलाव किए जा सकते हैं.
  4. Bazel के रखरखाव करने वालों के लिए, चेरी-पिक अनुरोध की समस्या का इस्तेमाल करके, बदलावों को बैकपोर्ट करना.

    • Bazel के रखरखाव करने वाले लोग, रिलीज़ शाखा में खास कमिट को चुनने का अनुरोध कर सकते हैं. यह प्रोसेस, GitHub पर चुनिंदा बदलावों को शामिल करने का अनुरोध बनाकर शुरू की जाती है. इसका तरीका यहां बताया गया है.

      1. चुनिंदा डेटा का अनुरोध खोलें
      2. अनुरोध की जानकारी भरें
        • टाइटल: अनुरोध के बारे में कम शब्दों और ज़्यादा जानकारी देने वाला टाइटल दें.
        • कमिट आईडी: उन कमिट के आईडी डालें जिन्हें आपको चुनना है. अगर एक से ज़्यादा कमिट हैं, तो उन्हें कॉमा लगाकर अलग करें.
        • कैटगरी: अनुरोध की कैटगरी बताएं.
        • समीक्षक: एक से ज़्यादा समीक्षकों के लिए, उनके GitHub आईडी को कॉमा लगाकर अलग करें.
      3. माइलस्टोन सेट करना
        • "माइलस्टोन" सेक्शन ढूंढें और सेटिंग पर क्लिक करें.
        • X.Y.Z रिलीज़ ब्लॉक करने वाले सही टूल चुनें. इस कार्रवाई से "रिलीज़-X.Y.Z" ब्रांच के लिए आपके अनुरोध को प्रोसेस करने के लिए, चेरी-पिक बॉट को ट्रिगर किया जाएगा.
      4. समस्या सबमिट करना
        • सभी जानकारी भरने और जगह की जानकारी सेट करने के बाद, समस्या सबमिट करें.
    • चेरी-पिक बॉट, अनुरोध को प्रोसेस करेगा और यह सूचना देगा कि क्या कमिट, चेरी-पिक करने की ज़रूरी शर्तें पूरी करती हैं. अगर कमिट को चुनने की सुविधा उपलब्ध है, तो इसका मतलब है कि कमिट को चुनते समय मर्ज करने से जुड़ी कोई समस्या नहीं है. ऐसे में, बॉट एक नया पुल अनुरोध बनाएगा. जब Bazel टीम के किसी सदस्य से पुश अनुरोध को मंज़ूरी मिल जाती है, तो कमिट को चुनकर रिलीज़ शाखा में मर्ज कर दिया जाता है. चुनिंदा डेटा को चुनने के लिए किए गए अनुरोध का विज़ुअल उदाहरण देखने के लिए, यह उदाहरण देखें .

  5. रिलीज़ को रोकने वाली समस्याओं की पहचान करना और रिलीज़ शाखा पर मिली समस्याओं को ठीक करना.

    • रिलीज़ ब्रांच को बेज़ल सीआई पर, उसी टेस्ट सुइट के साथ postsubmit और डाउनस्ट्रीम टेस्ट पाइपलाइन के साथ टेस्ट किया जाता है. Bazel टीम, रिलीज़ ब्रैंच की जांच के नतीजों पर नज़र रखती है और किसी भी तरह की गड़बड़ी को ठीक करती है.
  6. रिलीज़ के सभी संभावित अवरोधों को ठीक करने के बाद, रिलीज़ ब्रैंच से नई रिलीज़ बनाएं.

    • रिलीज़ कैंडिडेट के बारे में bazu-चर्चा, बज़ेल टीम करती है और उम्मीदवार के लिए बनाई गई कम्यूनिटी से जुड़ी गड़बड़ियों की रिपोर्ट पर नज़र रखी जाती है.
    • अगर रिलीज़ करने वाले नए ब्लॉकर की पहचान हो जाती है, तो आखिरी चरण पर वापस जाएं और सभी समस्याओं को ठीक करने के बाद, नया रिलीज़ कैंडिडेट बनाएं.
    • पहली रिलीज़ कैंडिडेट बनाने के बाद, रिलीज़ शाखा में नई सुविधाओं को जोड़ने की अनुमति नहीं है. सिर्फ़ गंभीर गड़बड़ियों को ठीक करने के लिए, चुनिंदा बदलाव किए जा सकते हैं. अगर चुनिंदा बदलावों की ज़रूरत है, तो अनुरोध करने वाले को इन सवालों के जवाब देने होंगे: यह बदलाव क्यों ज़रूरी है और इससे क्या फ़ायदे मिलेंगे? इस बदलाव से रिग्रेशन शुरू होने की कितनी संभावना है?
  7. अगर रिलीज़ को ब्लॉक करने वाली कोई और समस्या नहीं मिलती है, तो रिलीज़ कैंडिडेट को आधिकारिक रिलीज़ के तौर पर पुश करें

    • पैच रिलीज़ के लिए, रिलीज़ को आखिरी रिलीज़ कैंडिडेट के रिलीज़ होने के कम से कम दो कामकाजी दिन बाद पुश करें.
    • बड़ी और छोटी रिलीज़ के लिए, रिलीज़ को आखिरी रिलीज़ कैंडिडेट के रिलीज़ होने के दो कामकाजी दिन बाद पुश करें. हालांकि, रिलीज़ को पहले रिलीज़ कैंडिडेट के रिलीज़ होने के एक हफ़्ते बाद ही पुश करें.
    • रिलीज़ सिर्फ़ उस दिन पॉश की जाती है जब अगला दिन कामकाजी दिन हो.
    • रिलीज़ का एलान bazel-discuss पर किया जाता है. साथ ही, Bazel टीम नई रिलीज़ के लिए, कम्यूनिटी की गड़बड़ी की रिपोर्ट मॉनिटर करती है और उनका समाधान करती है.

रिपोर्ट में गिरावट

अगर किसी उपयोगकर्ता को Bazel की नई रिलीज़, रिलीज़ कैंडिडेट या HEAD में मौजूद Bazel में कोई गड़बड़ी मिलती है, तो कृपया GitHub पर गड़बड़ी की शिकायत करें. गड़बड़ी वाले कमिट को अलग-अलग हिस्सों में बांटने के लिए, Bazelisk का इस्तेमाल किया जा सकता है. साथ ही, इस जानकारी को गड़बड़ी की रिपोर्ट में शामिल किया जा सकता है.

उदाहरण के लिए, अगर आपका बिल्ड Bazel 6.1.0 के साथ काम करता है, लेकिन 6.2.0 के दूसरे रिलीज़ कैंडिडेट के साथ काम नहीं करता है, तो

bazelisk --bisect=6.1.0..release-6.2.0rc2 build //foo:bar

अगर आपको समस्या को फिर से दोहराना है, तो BAZELISK_SHUTDOWN या BAZELISK_CLEAN एनवायरमेंट वैरिएबल सेट करके, बज़ल के संबंधित निर्देश चलाकर, बिल्ड की स्थिति को रीसेट किया जा सकता है. ज़्यादा जानकारी के लिए, Bazelisk के बाइसेक्ट की सुविधा के बारे में दस्तावेज़ देखें.

bisect सुविधा का इस्तेमाल करने के लिए, Bazelisk को नए वर्शन पर अपग्रेड करना न भूलें.

नियम के साथ काम करना

अगर आप नियम बनाने वाले हैं और आपको Bazel के अलग-अलग वर्शन के साथ काम करने वाले नियम बनाने हैं, तो कृपया नियम के साथ काम करने वाले वर्शन पेज पर जाएं.