रिलीज़ मॉडल

ओरिजनल ब्लॉग पोस्ट में बताया गया है कि 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 के अगले एलटीएस वर्शन की झलक है.
• रोलिंग रिलीज़ में, ऐसे बदलाव शामिल हो सकते हैं जो काम नहीं करते. बड़े बदलावों के लिए, काम न करने वाले फ़्लैग इस्तेमाल करने का सुझाव दिया जाता है. काम न करने वाले बदलावों को रोल आउट करने के लिए, पिछले वर्शन के साथ काम करने की हमारी नीति का पालन करना चाहिए.

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

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