रिलीज़ मॉडल

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

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

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

सपोर्ट मैट्रिक्स

एलटीएस रिलीज़	सहायता का चरण	सबसे नया वर्शन	सहायता बंद होने की तारीख
Bazel 10	लगातार	रोलिंग रिलीज़ पेज देखना	लागू नहीं
Bazel 9	चालू है	9.3.0	दिसंबर 2028
Bazel 8	रखरखाव	8.8.1	दिसंबर 2027
Bazel 7	रखरखाव	7.7.1	दिसंबर 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 के अगले एलटीएस वर्शन की झलक है.
• रोलिंग रिलीज़ में, ऐसे बदलाव शामिल हो सकते हैं जो आपके सिस्टम के साथ काम न करें. बड़े नुकसान पहुंचा सकने वाले बदलावों के लिए, काम न करने वाले फ़्लैग इस्तेमाल करने का सुझाव दिया जाता है. काम न करने वाले नुकसान पहुंचा सकने वाले बदलावों को रोल आउट करने के लिए, पुराने सिस्टम के साथ काम करने की सुविधा से जुड़ी हमारी नीति का पालन करना चाहिए.

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

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

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

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

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

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

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

4. Bazel के रखरखाव करने वालों के लिए, Cherry-Pick Request Issue का इस्तेमाल करके बदलावों को बैकपोर्ट करें.

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