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