मूल ब्लॉग पोस्ट में बताया गया है कि Bazel 4.0 और इसके बाद के वर्शन में, रिलीज़ के दो ट्रैक काम करते हैं: रोलिंग रिलीज़ और लंबे समय तक सहायता (एलटीएस) वाली रिलीज़. इस पेज पर, Bazel के रिलीज़ मॉडल के बारे में नई जानकारी दी गई है.
सहायता मैट्रिक्स
| एलटीएस रिलीज़ | सहायता का चरण | सबसे नया वर्शन | सहायता बंद होने की तारीख |
|---|---|---|---|
| Bazel 10 | लगातार | रोलिंग रिलीज़ पेज देखना | लागू नहीं |
| Bazel 9 | चालू है | 9.1.1 | दिसंबर 2028 |
| Bazel 8 | रखरखाव | 8.7.0 | दिसंबर 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 LTS की सभी रिलीज़, 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 महीने में, एक नई एलटीएस रिलीज़ होने की उम्मीद है. एलटीएस का नया वर्शन रिलीज़ होने के बाद, वह तुरंत ऐक्टिव स्टेज में चला जाता है. वहीं, एलटीएस का पिछला वर्शन मेंटेनेंस स्टेज में चला जाता है.
- माइनर रिलीज़: ऐक्टिव एलटीएस ट्रैक पर नए माइनर वर्शन, हर दो महीने में एक बार रिलीज़ किए जाते हैं.
- पैच रिलीज़: ऐक्टिव और रखरखाव के चरणों में एलटीएस रिलीज़ के लिए नए पैच वर्शन, गंभीर बग ठीक करने के लिए मांग पर रिलीज़ किए जाएंगे.
- Bazel की एलटीएस रिलीज़, दो साल तक रखरखाव के चरण में रहने के बाद, बंद होने के चरण में पहुंच जाती है.
प्लान की गई रिलीज़ के लिए, कृपया GitHub पर रिलीज़ से जुड़ी समस्याएं देखें.
रिलीज़ करने की प्रक्रिया और नीतियां
रोलिंग रिलीज़ के लिए, प्रोसेस आसान है: हर दो हफ़्ते में, एक नई रिलीज़ बनाई जाती है. यह Google की इंटरनल Blaze रिलीज़ के बेसलाइन के मुताबिक होती है. त्वरित रिलीज़ करने के शेड्यूल की वजह से, हम रोलिंग रिलीज़ में कोई भी बदलाव वापस नहीं लाते हैं.
एलटीएस रिलीज़ के लिए, यहां दी गई प्रोसेस और नीतियों का पालन किया जाता है:
- रिलीज़ के लिए बेसलाइन कमिट तय करें.
- एलटीएस के नए मेजर वर्शन के लिए, बेसलाइन कमिट, मुख्य ब्रांच का HEAD होता है.
- माइनर या पैच रिलीज़ के लिए, बेसलाइन कमिट, उसी एलटीएस रिलीज़ के मौजूदा सबसे नए वर्शन का HEAD होता है.
- बेसलाइन कमिट से
release-<version>के नाम से रिलीज़ ब्रांच बनाएं. - रिलीज़ ब्रांच में पीआर के ज़रिए बदलावों को बैकपोर्ट करें.
- कम्यूनिटी, कुछ कमिट को वापस पोर्ट करने का सुझाव दे सकती है. इसके लिए, GitHub की समस्याओं या पीआर से जुड़ी समस्याओं पर "
@bazel-io flag" का जवाब दें. इससे उन्हें संभावित रिलीज़ ब्लॉकर के तौर पर मार्क किया जा सकेगा. Bazel टीम, इन समस्याओं को प्राथमिकता के हिसाब से व्यवस्थित करती है और यह तय करती है कि कमिट को वापस पोर्ट करना है या नहीं. - सिर्फ़ मुख्य ब्रांच पर किए गए ऐसे कमिट वापस लाए जा सकते हैं जो पुराने सिस्टम के साथ काम करते हैं. मर्ज करने से जुड़ी समस्याओं को हल करने के लिए, कुछ और छोटे-मोटे बदलाव किए जा सकते हैं.
- कम्यूनिटी, कुछ कमिट को वापस पोर्ट करने का सुझाव दे सकती है. इसके लिए, GitHub की समस्याओं या पीआर से जुड़ी समस्याओं पर "
Bazel के रखरखाव करने वालों के लिए, Cherry-Pick Request Issue का इस्तेमाल करके बदलावों को बैकपोर्ट करें.
Bazel को मैनेज करने वाले लोग, रिलीज़ ब्रांच में किसी खास कोड के बदलावों को दूसरी जगह लागू करने का अनुरोध कर सकते हैं. यह प्रोसेस, GitHub पर कोड के बदलावों को दूसरी जगह लागू करने का अनुरोध बनाकर शुरू की जाती है. इसे करने का तरीका यहां बताया गया है.
- चुनिंदा कमिट को शामिल करने का अनुरोध खोलें
- अनुरोध की जानकारी डालें
- टाइटल: अनुरोध के लिए, छोटा और जानकारी देने वाला टाइटल दें.
- कमिट आईडी: उन कमिट के आईडी डालें जिन्हें आपको चेरी-पिक करना है. अगर एक से ज़्यादा कमिट हैं, तो उन्हें कॉमा लगाकर अलग करें.
- कैटगरी: अनुरोध की कैटगरी बताएं.
- समीक्षक: एक से ज़्यादा समीक्षकों के लिए, उनके GitHub आईडी को कॉमा लगाकर अलग करें.
- उपलब्धि सेट करें
- "माइलस्टोन" सेक्शन ढूंढें और सेटिंग पर क्लिक करें.
- X.Y.Z रिलीज़ को ब्लॉक करने वाले सही विकल्प चुनें. इस कार्रवाई से, कोड के बदलावों को दूसरी जगह लागू करने वाले बॉट को "release-X.Y.Z" ब्रांच के लिए आपके अनुरोध को प्रोसेस करने का ट्रिगर मिलता है.
- समस्या की शिकायत सबमिट करें
- सभी जानकारी भरने और माइलस्टोन सेट करने के बाद, समस्या सबमिट करें.
चेरी-पिक बॉट, अनुरोध को प्रोसेस करेगा. साथ ही, अगर कमिट कोड के बदलावों को दूसरी जगह लागू करने की ज़रूरी शर्तें पूरी करते हैं, तो इसकी सूचना देगा. अगर कमिट को चेरी-पिक किया जा सकता है, तो इसका मतलब है कि कमिट को चेरी-पिक करते समय कोई मर्ज कॉन्फ़्लिक्ट नहीं है. ऐसे में, बॉट एक नया पुल अनुरोध बनाएगा. जब Bazel टीम का कोई सदस्य पुल अनुरोध को स्वीकार कर लेता है, तो कमिट को चुनिंदा तौर पर चुना जाता है और रिलीज़ ब्रांच में मर्ज कर दिया जाता है. पूरी हो चुकी कोड के बदलावों को दूसरी जगह लागू करने के अनुरोध का विज़ुअल उदाहरण देखने के लिए, इस उदाहरण को देखें .
रिलीज़ को ब्लॉक करने वाली समस्याओं का पता लगाएं और रिलीज़ ब्रांच में मिली समस्याओं को ठीक करें.
- रिलीज़ ब्रांच की जांच, Bazel CI पर postsubmit और डाउनस्ट्रीम टेस्ट पाइपलाइन में एक ही टेस्ट सुइट से की जाती है. Bazel टीम, रिलीज़ ब्रांच के टेस्टिंग के नतीजों पर नज़र रखती है और मिली किसी भी रिग्रेशन को ठीक करती है.
जब रिलीज़ से जुड़ी सभी समस्याएं ठीक हो जाएं, तब रिलीज़ ब्रांच से नया रिलीज़ कैंडिडेट बनाएं.
- रिलीज़ कैंडिडेट की सूचना bazel-discuss पर दी जाती है. Bazel टीम, कैंडिडेट के लिए कम्यूनिटी की ओर से भेजी गई गड़बड़ी की रिपोर्ट पर नज़र रखती है.
- अगर रिलीज़ में रुकावट डालने वाली नई समस्याएं मिलती हैं, तो पिछले चरण पर वापस जाएं. इसके बाद, सभी समस्याओं को हल करने के बाद, रिलीज़ के लिए नया कैंडिडेट बनाएं.
- रिलीज़ ब्रांच में नई सुविधाएं तब तक नहीं जोड़ी जा सकतीं, जब तक कि पहला रिलीज़ कैंडिडेट नहीं बन जाता. कोड के बदलावों को दूसरी जगह लागू करने की सुविधा सिर्फ़ ज़रूरी फ़िक्स के लिए उपलब्ध है. अगर कोड के बदलावों को दूसरी जगह लागू करने की ज़रूरत है, तो अनुरोध करने वाले व्यक्ति को इन सवालों के जवाब देने होंगे: यह बदलाव क्यों ज़रूरी है और इससे क्या फ़ायदे मिलते हैं? इस बदलाव से रिग्रेशन होने की कितनी संभावना है?
अगर रिलीज़ कैंडिडेट में कोई और समस्या नहीं मिलती है, तो उसे आधिकारिक रिलीज़ के तौर पर पुश करें
- पैच रिलीज़ के लिए, रिलीज़ को कम से कम दो कामकाजी दिन बाद पुश करें. ऐसा तब करें, जब रिलीज़ कैंडिडेट का आखिरी वर्शन रिलीज़ हो गया हो.
- मुख्य और सामान्य रिलीज़ के लिए, रिलीज़ को आखिरी रिलीज़ कैंडिडेट के रिलीज़ होने के दो कामकाजी दिनों के बाद पुश करें. हालांकि, इसे पहले रिलीज़ कैंडिडेट के रिलीज़ होने के एक हफ़्ते से पहले पुश न करें.
- रिलीज़ को सिर्फ़ उस दिन पुश किया जाता है जब अगला दिन कामकाजी दिन हो.
- इस रिलीज़ की सूचना bazel-discuss पर दी गई है. 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 के अलग-अलग वर्शन के साथ काम करने वाले नियम बनाने हैं, तो कृपया नियम के साथ काम करने वाले वर्शन पेज देखें.