इस पेज पर, बैकवर्ड कंपैटिबिलिटी को मैनेज करने के तरीके के बारे में जानकारी दी गई है. इसमें एक रिलीज़ से दूसरी रिलीज़ पर माइग्रेट करने और कंपैटिबल न होने वाले बदलावों के बारे में बताने का तरीका शामिल है.
Bazel में लगातार बदलाव हो रहे हैं. एलटीएस के मुख्य वर्शन के हिस्से के तौर पर रिलीज़ किए गए माइनर वर्शन, पूरी तरह से पुराने वर्शन के साथ काम करते हैं. एलटीएस की नई मुख्य रिलीज़ में ऐसे बदलाव हो सकते हैं जो काम नहीं करते. इसके लिए, माइग्रेशन की ज़रूरत होती है. Bazel के रिलीज़ मॉडल के बारे में ज़्यादा जानने के लिए, कृपया रिलीज़ मॉडल पेज देखें.
खास जानकारी
- हमारा सुझाव है कि बड़े बदलावों के लिए,
--incompatible_*फ़्लैग का इस्तेमाल करें. - हर
--incompatible_*फ़्लैग के लिए, GitHub की समस्या में व्यवहार में हुए बदलाव के बारे में बताया गया है. साथ ही, माइग्रेशन से जुड़ी जानकारी देने का मकसद है. - सुझाव दिया जाता है कि काम न करने वाले फ़्लैग को डिफ़ॉल्ट रूप से चालू किए बिना, एलटीएस की नई रिलीज़ में वापस पोर्ट किया जाए.
--experimental_*फ़्लैग से सुरक्षित किए गए एपीआई और उनके काम करने के तरीके में कभी भी बदलाव किया जा सकता है.--experimental_*या--incompatible_*फ़्लैग के साथ कभी भी प्रोडक्शन बिल्ड न चलाएं.
इस नीति का पालन करने का तरीका
- Bazel का इस्तेमाल करने वाले लोगों के लिए - Bazel को अपडेट करने का तरीका
- योगदान देने वालों के लिए - काम न करने वाले बदलावों के सबसे सही तरीके
- रिलीज़ मैनेजर के लिए - समस्या के लेबल और रिलीज़ को अपडेट करने का तरीका
स्टेबल फ़ंक्शन क्या है?
आम तौर पर, --experimental_... फ़्लैग के बिना वाले एपीआई या व्यवहार को Bazel में स्थिर और काम करने वाली सुविधाएं माना जाता है.
इसमें इस तरह का कॉन्टेंट शामिल है:
- Starlark भाषा और एपीआई
- Bazel के साथ बंडल किए गए नियम
- Bazel API, जैसे कि रिमोट एक्ज़ीक्यूशन एपीआई या Build Event Protocol
- फ़्लैग और उनके सिमैंटिक
बदलावों और माइग्रेशन के तरीकों के साथ काम न करने वाली समस्याएं
Bazel टीम का मकसद, नई रिलीज़ में हर ऐसे बदलाव के लिए माइग्रेशन रेसिपी उपलब्ध कराना है जो काम नहीं करती. इससे आपको अपने कोड को अपडेट करने में मदद मिलती है. जैसे, BUILD और .bzl फ़ाइलें, स्क्रिप्ट में Bazel का इस्तेमाल, Bazel API का इस्तेमाल वगैरह.
ऐसे बदलावों के लिए, --incompatible_* फ़्लैग और GitHub में इससे जुड़ी समस्या होनी चाहिए.
हमारा सुझाव है कि ऐसे फ़्लैग और उनसे जुड़े बदलावों को, एलटीएस के सबसे नए वर्शन में बैक-पोर्ट किया जाए. हालांकि, ऐसा डिफ़ॉल्ट रूप से फ़्लैग को चालू किए बिना किया जाना चाहिए. इससे उपयोगकर्ताओं को, अगली एलटीएस रिलीज़ उपलब्ध होने से पहले, उन बदलावों के लिए माइग्रेट करने की अनुमति मिलती है जो काम नहीं करते.
ज़रूरी शर्तें पूरी न करने वाले बदलावों की जानकारी देना
बेमेल बदलावों के बारे में जानकारी का मुख्य सोर्स, GitHub की समस्याएं हैं. इन समस्याओं को "incompatible-change" लेबल से मार्क किया जाता है.
हर ऐसे बदलाव के लिए, समस्या में यह जानकारी दी जाती है:
- उस फ़्लैग का नाम जो अमान्य बदलाव को कंट्रोल करता है
- बदले गए फ़ंक्शन के बारे में जानकारी
- माइग्रेशन रेसिपी
जब Bazel के HEAD वर्शन के साथ माइग्रेट करने के लिए, काम न करने वाला कोई बदलाव तैयार हो जाता है (इसलिए, Bazel के अगले रोलिंग रिलीज़ के साथ भी), तो उसे migration-ready लेबल के साथ मार्क किया जाना चाहिए. जब HEAD पर, काम न करने वाले बदलाव का फ़्लैग बदल दिया जाता है, तब काम न करने वाले बदलाव की समस्या बंद हो जाती है.