रिलीज़ मॉडल

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

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

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