रिलीज़ मॉडल

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

Nightly · 9.2 · 9.1 · 9.0 · 8.7 · 8.6

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

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

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

   • Bazel के रखरखाव करने वाले लोग, रिलीज़ ब्रांच के लिए, चेरी-पिक के खास कमिट का अनुरोध कर सकते हैं. यह प्रोसेस, GitHub पर कोड के बदलावों को दूसरी जगह लागू करने का अनुरोध करके शुरू की जाती है. इसे करने का तरीका यहां बताया गया है.

     1. चेरी-पिक का अनुरोध खोलें
     2. अनुरोध की जानकारी डालें
        • टाइटल: अनुरोध के लिए, साफ़ और जानकारी देने वाला टाइटल डालें.
        • कमिट आईडी: उन कमिट के आईडी डालें जिन्हें आपको चेरी-पिक करना है. अगर एक से ज़्यादा कमिट हैं, तो उन्हें कॉमा लगाकर अलग करें.
        • कैटगरी: अनुरोध की कैटगरी तय करें.
        • समीक्षक: एक से ज़्यादा समीक्षकों के लिए, उनके GitHub आईडी को कॉमा लगाकर अलग करें.
     3. माइलस्टोन सेट करें
        • "माइलस्टोन" सेक्शन ढूंढें और सेटिंग पर क्लिक करें.
        • X.Y.Z रिलीज़ में आने वाली समस्याओं के लिए, सही विकल्प चुनें. इस कार्रवाई से, चेरी-पिक बॉट, "release-X.Y.Z" ब्रांच के लिए आपके अनुरोध को प्रोसेस करेगा.
     4. समस्या सबमिट करें
        • सारी जानकारी डालने और माइलस्टोन सेट करने के बाद, समस्या सबमिट करें.

   • कोड के बदलावों को दूसरी जगह लागू करने वाला बॉट, अनुरोध को प्रोसेस करेगा. साथ ही, यह सूचना देगा कि कमिट, कोड के बदलावों को दूसरी जगह लागू करने के लिए ज़रूरी शर्तें पूरी करते हैं या नहीं. अगर कमिट को चेरी-पिक किया जा सकता है, तो इसका मतलब है कि कमिट को चेरी-पिक करते समय, मर्ज से जुड़ी कोई समस्या नहीं है. इसके बाद, बॉट एक नया पुल का अनुरोध बनाएगा. जब Bazel की टीम का कोई सदस्य, पुल अनुरोध को मंज़ूरी दे देता है, तब कमिट को चेरी-पिक किया जाता है और रिलीज़ ब्रांच में मर्ज कर दिया जाता है. चेरी-पिक के पूरे अनुरोध का विज़ुअल उदाहरण देखने के लिए, यह उदाहरण देखें.

5. रिलीज़ में आने वाली समस्याओं की पहचान करें और रिलीज़ ब्रांच में मिली समस्याओं को ठीक करें.

   • रिलीज़ ब्रांच की जांच, Bazel सीआई पर 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 की बिसेक्ट सुविधा के बारे में दस्तावेज़ देखें.

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

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

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