पुराने सिस्टम के साथ काम करने की सुविधा

समस्या की शिकायत करें सोर्स देखें Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

इस पेज पर, बैकवर्ड कंपैटिबिलिटी को मैनेज करने के तरीके के बारे में जानकारी दी गई है. इसमें एक रिलीज़ से दूसरी रिलीज़ पर माइग्रेट करने का तरीका और ऐसे बदलावों के बारे में जानकारी देने का तरीका शामिल है जो काम नहीं करते.

Bazel को बेहतर बनाया जा रहा है. एलटीएस के मुख्य वर्शन के हिस्से के तौर पर रिलीज़ किए गए माइनर वर्शन, पुराने वर्शन के साथ पूरी तरह से काम करते हैं. एलटीएस की नई मुख्य रिलीज़ में ऐसे बदलाव हो सकते हैं जो काम नहीं करते. इसके लिए, माइग्रेशन की प्रोसेस पूरी करनी होगी. Bazel के रिलीज़ मॉडल के बारे में ज़्यादा जानने के लिए, कृपया रिलीज़ मॉडल पेज देखें.

खास जानकारी

  1. हमारा सुझाव है कि बड़े बदलावों के लिए, --incompatible_* फ़्लैग का इस्तेमाल करें.
  2. हर --incompatible_* फ़्लैग के लिए, GitHub की समस्या में व्यवहार में हुए बदलाव के बारे में बताया गया है. साथ ही, माइग्रेशन से जुड़ी जानकारी देने का मकसद है.
  3. सुझाव दिया जाता है कि ऐसे फ़्लैग को डिफ़ॉल्ट रूप से चालू किए बिना, एलटीएस के नए वर्शन में वापस पोर्ट किया जाए जो काम नहीं करते.
  4. --experimental_* फ़्लैग से सुरक्षित किए गए एपीआई और उनके काम करने के तरीके में कभी भी बदलाव किया जा सकता है.
  5. --experimental_* या --incompatible_* फ़्लैग के साथ कभी भी प्रोडक्शन बिल्ड न चलाएं.

इस नीति का पालन करने का तरीका

स्टेबल फ़ंक्शनैलिटी क्या होती है?

आम तौर पर, --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 पर, काम न करने वाले बदलाव का फ़्लैग फ़्लिप किया जाता है, तब काम न करने वाले बदलाव की समस्या बंद हो जाती है.