जैसा कि ओरिजनल ब्लॉग पोस्ट में बताया गया है, Bazel 4.0 और इसके बाद के वर्शन, रिलीज़ के दो ट्रैक के साथ काम करते हैं: रोलिंग रिलीज़ और लंबे समय तक सहायता (एलटीएस) वाली रिलीज़. इस पेज पर, Bazel के रिलीज़ मॉडल के बारे में नई जानकारी दी गई है.
सहायता मैट्रिक्स
| एलटीएस रिलीज़ | सहायता का चरण | सबसे नया वर्शन | सहायता बंद होने की तारीख |
|---|---|---|---|
| Bazel 9 | रोलिंग | रोलिंग रिलीज़ वाला पेज देखें | लागू नहीं |
| Bazel 8 | चालू है | 8.4.2 | दिसंबर 2027 |
| Bazel 7 | रखरखाव | 7.7.0 | दिसंबर 2026 |
| Bazel 6 | रखरखाव | 6.5.0 | दिसंबर 2025 |
| Bazel 5 | बहिष्कृत | 5.4.1 | जनवरी 2025 |
| Bazel 4 | बहिष्कृत | 4.2.4 | जनवरी 2024 |
Bazel की एलटीएस रिलीज़ के बारे में जानकारी, 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 की एलटीएस की अगली रिलीज़ की झलक होती है.
- रोलिंग रिलीज़ में, पुराने सिस्टम के साथ काम न करने वाले बदलाव शामिल हो सकते हैं. बड़े बदलावों के लिए, पुराने सिस्टम के साथ काम न करने वाले फ़्लैग इस्तेमाल करने का सुझाव दिया जाता है. पुराने सिस्टम के साथ काम न करने वाले बदलावों को रोल आउट करने के लिए, पुराने सिस्टम के साथ काम करने की हमारी नीति का पालन करना चाहिए.
एलटीएस रिलीज़
- मेजर रिलीज़: एलटीएस की नई रिलीज़, HEAD से हर 12 महीने में रिलीज़ की जाती है. एलटीएस की नई रिलीज़ होने के बाद, यह तुरंत 'चालू है' चरण में आ जाती है. वहीं, एलटीएस की पिछली रिलीज़, 'रखरखाव' चरण में चली जाती है.
- माइनर रिलीज़: एलटीएस के 'चालू है' ट्रैक पर, माइनर वर्शन हर दो महीने में रिलीज़ किए जाते हैं.
- पैच रिलीज़: एलटीएस की 'चालू है' और 'रखरखाव' चरण वाली रिलीज़ के लिए, पैच के नए वर्शन, गंभीर गड़बड़ियों को ठीक करने के लिए मांग पर रिलीज़ किए जाते हैं.
- Bazel की एलटीएस रिलीज़, 'रखरखाव' चरण में दो साल तक रहने के बाद, 'बहिष्कृत' चरण में चली जाती है.
रिलीज़ की योजना के बारे में जानने के लिए, कृपया हमारे रिलीज़ से जुड़ी समस्याएं Github पर देखें.
रिलीज़ करने का तरीका और नीतियां
रोलिंग रिलीज़ के लिए, प्रोसेस आसान है: हर दो हफ़्ते में, एक नई रिलीज़ बनाई जाती है. यह रिलीज़, Google की इंटरनल Blaze रिलीज़ के जैसी ही होती है. रिलीज़ की फ़्रीक्वेंसी ज़्यादा होने की वजह से, हम रोलिंग रिलीज़ में कोई बदलाव पोर्ट नहीं करते.
एलटीएस रिलीज़ के लिए, यहां दिया गया तरीका और नीतियां अपनाई जाती हैं:
- रिलीज़ के लिए, बेसलाइन कमिट तय करें.
- एलटीएस की नई मेजर रिलीज़ के लिए, बेसलाइन कमिट, मुख्य ब्रांच का HEAD होता है.
- माइनर या पैच रिलीज़ के लिए, बेसलाइन कमिट, एलटीएस की उसी रिलीज़ के मौजूदा सबसे नए वर्शन का HEAD होता है.
- बेसलाइन
कमिट से,
release-<version>नाम की रिलीज़ ब्रांच बनाएं. - पीआर की मदद से, रिलीज़ ब्रांच में बदलाव पोर्ट करें.
- कम्यूनिटी, GitHub पर रिलीज़ या पीआर से जुड़ी समस्याओं पर "
@bazel-io flag" का जवाब देकर, कुछ कमिट को पोर्ट करने का सुझाव दे सकती है. इससे उन्हें रिलीज़ में आने वाली संभावित समस्याओं के तौर पर मार्क किया जा सकता है. Bazel की टीम, इन समस्याओं को हल करती है और यह तय करती है कि कमिट को पोर्ट किया जाए या नहीं. - मुख्य ब्रांच पर, पुराने सिस्टम के साथ काम करने वाले कमिट को ही पोर्ट किया जा सकता है. मर्ज से जुड़ी समस्याओं को हल करने के लिए, माइनर बदलाव किए जा सकते हैं.
- कम्यूनिटी, GitHub पर रिलीज़ या पीआर से जुड़ी समस्याओं पर "
Bazel के रखरखाव करने वाले लोगों के लिए, चेरी-पिक करने के अनुरोध से जुड़ी समस्या का इस्तेमाल करके, बदलाव पोर्ट करें.
Bazel के रखरखाव करने वाले लोग, रिलीज़ ब्रांच में चेरी-पिक करने के लिए, खास कमिट का अनुरोध कर सकते हैं. यह प्रोसेस, GitHub पर चेरी-पिक करने का अनुरोध करके शुरू की जाती है. इसे करने का तरीका यहां बताया गया है.
- चेरी-पिक करने का अनुरोध खोलें
- अनुरोध की जानकारी डालें
- टाइटल: अनुरोध के लिए, साफ़ और जानकारी देने वाला टाइटल डालें.
- कमिट आईडी: उन कमिट के आईडी डालें जिन्हें आपको चेरी-पिक करना है. अगर एक से ज़्यादा कमिट हैं, तो उन्हें कॉमा लगाकर अलग करें.
- कैटेगरी: अनुरोध की कैटेगरी तय करें.
- समीक्षक: एक से ज़्यादा समीक्षकों के लिए, उनके GitHub आईडी को कॉमा लगाकर अलग करें.
- माइलस्टोन सेट करें
- "माइलस्टोन" सेक्शन ढूंढें और सेटिंग पर क्लिक करें.
- X.Y.Z रिलीज़ में आने वाली समस्याओं के लिए सही विकल्प चुनें. इससे चेरी-पिक करने वाला बॉट, "release-X.Y.Z" ब्रांच के लिए आपके अनुरोध को प्रोसेस करेगा.
- समस्या सबमिट करें
- सारी जानकारी डालने और माइलस्टोन सेट करने के बाद, समस्या सबमिट करें.
चेरी-पिक करने वाला बॉट, अनुरोध को प्रोसेस करेगा. साथ ही, यह सूचना देगा कि कमिट, चेरी-पिक करने के लिए ज़रूरी शर्तें पूरी करते हैं या नहीं. अगर कमिट को चेरी-पिक किया जा सकता है, तो इसका मतलब है कि कमिट को चेरी-पिक करते समय, मर्ज से जुड़ी कोई समस्या नहीं है. इसके बाद, बॉट एक नया पुल करने का अनुरोध बनाएगा. जब Bazel की टीम का कोई सदस्य, पुल करने के अनुरोध को मंज़ूरी दे देता है, तब कमिट को चेरी-पिक किया जाता है और रिलीज़ ब्रांच में मर्ज कर दिया जाता है. चेरी-पिक करने के पूरे अनुरोध का विज़ुअल उदाहरण देखने के लिए, यह उदाहरण देखें .
रिलीज़ में आने वाली समस्याओं की पहचान करें और रिलीज़ ब्रांच में मिली समस्याओं को ठीक करें.
- रिलीज़ ब्रांच की जांच, Bazel सीआई पर postsubmit और डाउनस्ट्रीम टेस्ट पाइपलाइन में, उसी टेस्ट सुइट से की जाती है. Bazel की टीम, रिलीज़ ब्रांच के टेस्ट के नतीजों पर नज़र रखती है और मिली किसी भी समस्या को ठीक करती है.
रिलीज़ में आने वाली सभी समस्याओं को हल करने के बाद, रिलीज़ ब्रांच से रिलीज़ कैंडिडेट बनाएं.
- रिलीज़ कैंडिडेट के बारे में, bazel-discuss पर सूचना दी जाती है. Bazel की टीम, कैंडिडेट के लिए कम्यूनिटी की गड़बड़ी की रिपोर्ट पर नज़र रखती है.
- अगर रिलीज़ में आने वाली नई समस्याओं की पहचान की जाती है, तो पिछले चरण पर वापस जाएं और सभी समस्याओं को हल करने के बाद, रिलीज़ कैंडिडेट बनाएं.
- रिलीज़ कैंडिडेट बनाने के बाद, रिलीज़ ब्रांच में नई सुविधाएं नहीं जोड़ी जा सकतीं. चेरी-पिक करने की सुविधा का इस्तेमाल सिर्फ़ गंभीर गड़बड़ियों को ठीक करने के लिए किया जा सकता है. अगर चेरी-पिक करने की ज़रूरत है, तो अनुरोध करने वाले व्यक्ति को इन सवालों के जवाब देने होंगे: यह बदलाव क्यों ज़रूरी है और इससे क्या फ़ायदे मिलते हैं? इस बदलाव से, गड़बड़ी होने की कितनी संभावना है?
अगर रिलीज़ में आने वाली कोई समस्या नहीं मिलती है, तो रिलीज़ कैंडिडेट को आधिकारिक रिलीज़ के तौर पर पुश करें
- पैच रिलीज़ के लिए, रिलीज़ कैंडिडेट के रिलीज़ होने के कम से कम दो कामकाजी दिनों बाद, रिलीज़ को पुश करें.
- मेजर और माइनर रिलीज़ के लिए, रिलीज़ कैंडिडेट के रिलीज़ होने के दो कामकाजी दिनों बाद, रिलीज़ को पुश करें. हालांकि, रिलीज़ कैंडिडेट के रिलीज़ होने के एक हफ़्ते से पहले, रिलीज़ को पुश न करें.
- रिलीज़ को सिर्फ़ ऐसे दिन पुश किया जाता है जिसके अगले दिन कामकाजी दिन हो.
- रिलीज़ के बारे में, 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
की गड़बड़ी की वजह बनने वाले कमिट को अलग करने की सुविधा के बारे में दस्तावेज़ देखें.
गड़बड़ी की वजह बनने वाले कमिट को अलग करने की सुविधा का इस्तेमाल करने के लिए, Bazelisk को नए वर्शन पर अपग्रेड करना न भूलें.
नियमों के साथ काम करने की सुविधा
अगर आप नियमों के लेखक हैं और Bazel के अलग-अलग वर्शन के साथ काम करने की सुविधा बनाए रखना चाहते हैं, तो कृपया नियमों के साथ काम करने की सुविधा वाला पेज देखें.