रिलीज़ मॉडल

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

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

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

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

Bazel के सभी LTS रिलीज़, GitHub पर रिलीज़ पेज पर देखे जा सकते हैं.

ध्यान दें: Bazel 5 से पहले के वर्शन अब काम नहीं करते. Bazel का इस्तेमाल करने वाले लोगों को, LTS के नए वर्शन पर अपग्रेड करने का सुझाव दिया जाता है. अगर आपको HEAD में हुए नए बदलावों के बारे में अप-टू-डेट रहना है, तो रोलिंग रिलीज़ का इस्तेमाल करें.

रिलीज़ वर्शन

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

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

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

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

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

सहायता के चरण

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

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

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

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

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

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

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

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

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

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

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

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

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

4. Bazel के रखरखाव करने वालों के लिए, चेरी-पिक अनुरोध की समस्या का इस्तेमाल करके, बदलावों को बैकपोर्ट करना.

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

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

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

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

   • Bazel CI पर, रिलीज़ ब्रैंच की जांच, पोस्ट सबमिट और डाउनस्ट्रीम टेस्ट पाइपलाइन में एक ही टेस्ट सुइट के साथ की जाती है. Bazel टीम, रिलीज़ ब्रैंच की जांच के नतीजों पर नज़र रखती है और किसी भी तरह की गड़बड़ी को ठीक करती है.

6. रिलीज़ से जुड़ी सभी समस्याओं को हल करने के बाद, रिलीज़ ब्रैंच से नई रिलीज़ कैंडिडेट बनाएं.

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

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 के अलग-अलग वर्शन के साथ काम करने वाले नियम बनाने हैं, तो कृपया नियम के साथ काम करने वाले वर्शन पेज पर जाएं.