रिलीज़ मॉडल

समस्या की शिकायत करें सोर्स देखें

नाइटली रिलीज़ · 9.2 · 9.1 · 9.0 · 8.7 · 8.6

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

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

एलटीएस रिलीज़	सहायता स्टेज	सबसे नया वर्शन	सहायता बंद होने की तारीख
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	जनवरी 2024

Bazel LTS की सभी रिलीज़, GitHub पर रिलीज़ पेज पर देखी जा सकती हैं. GitHub पर "सबसे नया" बैज हमेशा सबसे नए सिमैंटिक वर्शन पर ले जाता है. भले ही, किसी पुराने वर्शन के लिए मेंटेनेंस पैच हाल ही में रिलीज़ किया गया हो.

रिलीज़ के लिए तैयार वर्शन

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

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

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

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

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

सहायता के चरण

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

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

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

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

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

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

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

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

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

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

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

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

1. रिलीज़ के लिए बेसलाइन कमिट तय करें.
   • एलटीएस के नए मेजर वर्शन के लिए, बेसलाइन कमिट, मुख्य ब्रांच का HEAD होता है.
   • किसी माइनर या पैच रिलीज़ के लिए, बेसलाइन कमिट उसी एलटीएस रिलीज़ के मौजूदा नए वर्शन का 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 पर postsubmit और डाउनस्ट्रीम टेस्ट पाइपलाइन में उसी टेस्ट सुइट से की जाती है. 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 एनवायरमेंट वैरिएबल सेट करें. इससे, उससे जुड़े bazel कमांड चलाए जा सकेंगे. ज़्यादा जानकारी के लिए, Bazelisk की bisect सुविधा के बारे में दस्तावेज़ देखें.

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

नियम के साथ काम करने वाले मोड

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