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