रिलीज़ मॉडल

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

नाइटली · 9.2 · 9.1 · 9.0 · 8.7 · 8.6

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

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

एलटीएस रिलीज़	सहायता का स्टेज	सबसे नया वर्शन	सहायता बंद होने की तारीख
Bazel 10	लगातार	रोलिंग रिलीज़ पेज देखें	लागू नहीं
Bazel 9	चालू है	9.3.2	दिसंबर 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 की सभी एलटीएस रिलीज़, 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 LTS रिलीज़, दो साल तक मेंटेनेंस स्टेज में रहने के बाद, बंद होने की स्टेज में पहुंच जाती है.

रिलीज़ के लिए शेड्यूल की गई सुविधाओं के बारे में जानने के लिए, कृपया 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 की नई रिलीज़, रिलीज़ कैंडिडेट या Bazel के HEAD वर्शन में कोई गड़बड़ी मिलती है, तो कृपया GitHub पर इसकी शिकायत करें. Bazelisk का इस्तेमाल करके, गड़बड़ी वाली कमिट को दो हिस्सों में बांटा जा सकता है. साथ ही, इस जानकारी को गड़बड़ी की रिपोर्ट में शामिल किया जा सकता है.

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

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

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

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

नियम के साथ काम करने की सुविधा

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