रिलीज़ मॉडल

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

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

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 रिलीज़ के बेसलाइन के मुताबिक होती है. रिलीज़ की फ़्रीक्वेंसी ज़्यादा होने की वजह से, हम रोलिंग रिलीज़ में कोई बदलाव शामिल नहीं करते.

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

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