TensorFlow संस्करण संगतता

यह दस्तावेज़ उन उपयोगकर्ताओं के लिए है जिन्हें TensorFlow (या तो कोड या डेटा के लिए) के विभिन्न संस्करणों में पश्चगामी संगतता की आवश्यकता है, और उन डेवलपर्स के लिए जो अनुकूलता बनाए रखते हुए TensorFlow को संशोधित करना चाहते हैं।

सिमेंटिक संस्करण 2.0

TensorFlow अपने सार्वजनिक एपीआई के लिए सिमेंटिक वर्जनिंग 2.0 (सेवर) का अनुसरण करता है। TensorFlow के प्रत्येक रिलीज़ संस्करण का रूप MAJOR.MINOR.PATCH होता है। उदाहरण के लिए, MINOR संस्करण 1.2.3 में MAJOR संस्करण 1, लघु संस्करण 2 और PATCH संस्करण 3 हैं। प्रत्येक संख्या में परिवर्तन के निम्नलिखित अर्थ हैं:

• प्रमुख : संभावित रूप से पीछे की ओर असंगत परिवर्तन। पिछले प्रमुख रिलीज़ के साथ काम करने वाले कोड और डेटा आवश्यक रूप से नए रिलीज़ के साथ काम नहीं करेंगे। हालाँकि, कुछ मामलों में मौजूदा TensorFlow ग्राफ़ और चेकपॉइंट नए रिलीज़ में माइग्रेट करने योग्य हो सकते हैं; डेटा संगतता पर विवरण के लिए ग्राफ़ और चेकपॉइंट की संगतता देखें।

• माइनर : बैकवर्ड संगत विशेषताएं, गति में सुधार, आदि। कोड और डेटा जो पिछले मामूली रिलीज के साथ काम करता है और जो केवल गैर-प्रयोगात्मक सार्वजनिक एपीआई पर निर्भर करता है, अपरिवर्तित काम करना जारी रखेगा। सार्वजनिक एपीआई क्या है और क्या नहीं है, इसके विवरण के लिए, क्या शामिल है देखें।

• PATCH : पश्चगामी संगत बग फिक्स।

उदाहरण के लिए, रिलीज़ 1.0.0 ने रिलीज़ 0.12.1 से पिछड़े असंगत परिवर्तन पेश किए। हालाँकि, रिलीज़ 1.1.1 रिलीज़ 1.0.0 के साथ पिछड़ा संगत था।

क्या ढका हुआ है

TensorFlow के केवल सार्वजनिक API छोटे और पैच संस्करणों में पिछड़े संगत हैं। सार्वजनिक एपीआई में शामिल हैं

• tensorflow मॉड्यूल और इसके सबमॉड्यूल्स में सभी प्रलेखित पायथन फ़ंक्शंस और कक्षाएं, को छोड़कर

  • निजी प्रतीक: कोई भी कार्य, वर्ग, आदि, जिसका नाम _ से शुरू होता है
  • प्रायोगिक और tf.contrib प्रतीक, विवरण के लिए नीचे देखें।

  ध्यान दें कि examples/ और tools/ निर्देशिका में कोड tensorflow पायथन मॉड्यूल के माध्यम से उपलब्ध नहीं है और इस प्रकार संगतता गारंटी द्वारा कवर नहीं किया गया है।

  यदि एक प्रतीक tensorflow पायथन मॉड्यूल या उसके सबमॉड्यूल के माध्यम से उपलब्ध है, लेकिन प्रलेखित नहीं है, तो इसे सार्वजनिक एपीआई का हिस्सा नहीं माना जाता है।

• संगतता एपीआई (पायथन में, tf.compat मॉड्यूल)। प्रमुख संस्करणों में, हम उपयोगकर्ताओं को एक नए प्रमुख संस्करण में संक्रमण के साथ मदद करने के लिए उपयोगिताओं और अतिरिक्त समापन बिंदु जारी कर सकते हैं। इन एपीआई प्रतीकों को हटा दिया गया है और समर्थित नहीं है (यानी, हम कोई फीचर नहीं जोड़ेंगे, और हम कमजोरियों को ठीक करने के अलावा बग को ठीक नहीं करेंगे), लेकिन वे हमारी संगतता गारंटी के अंतर्गत आते हैं।

• सी एपीआई ।

• निम्नलिखित प्रोटोकॉल बफ़र फ़ाइलें:

  • attr_value
  • config
  • event
  • graph
  • op_def
  • reader_base
  • summary
  • tensor
  • tensor_shape
  • types

क्या कवर नहीं किया गया है

TensorFlow के कुछ हिस्से किसी भी बिंदु पर पिछड़े असंगत तरीके से बदल सकते हैं। इसमें शामिल है:

• प्रायोगिक एपीआई : विकास की सुविधा के लिए, हम कुछ एपीआई प्रतीकों को संगतता गारंटी से स्पष्ट रूप से प्रयोगात्मक के रूप में चिह्नित करते हैं। विशेष रूप से, निम्नलिखित किसी भी संगतता गारंटी द्वारा कवर नहीं किए गए हैं:

  • tf.contrib मॉड्यूल या इसके सबमॉड्यूल में कोई प्रतीक;
  • कोई भी प्रतीक (मॉड्यूल, फ़ंक्शन, तर्क, संपत्ति, वर्ग, या स्थिर) जिसका नाम experimental या Experimental है; या
  • कोई प्रतीक जिसका पूरी तरह से योग्य नाम में मॉड्यूल या वर्ग शामिल है जो स्वयं प्रयोगात्मक है। इसमें experimental कहे जाने वाले किसी भी प्रोटोकॉल बफ़र के फ़ील्ड और सबमैसेज शामिल हैं।

• अन्य भाषाएँ : पायथन और C के अलावा अन्य भाषाओं में TensorFlow API, जैसे:

  • सी ++ ( tensorflow/cc में हेडर फाइलों के माध्यम से उजागर)।
  • जावा ,
  • जाओ
  • जावास्क्रिप्ट

• कंपोजिट ऑप्स का विवरण: पायथन में कई सार्वजनिक फ़ंक्शंस ग्राफ़ में कई आदिम ऑप्स तक विस्तारित होते हैं, और ये विवरण डिस्क में सहेजे गए किसी भी ग्राफ़ का हिस्सा होंगे, जैसे कि GraphDef एस। मामूली रिलीज के लिए ये विवरण बदल सकते हैं। विशेष रूप से, प्रतिगमन परीक्षण जो ग्राफ के बीच सटीक मिलान की जांच करते हैं, छोटे रिलीज में टूटने की संभावना है, भले ही ग्राफ का व्यवहार अपरिवर्तित होना चाहिए और मौजूदा चेकपॉइंट्स अभी भी काम करेंगे।

• फ़्लोटिंग पॉइंट संख्यात्मक विवरण: ऑप्स द्वारा गणना किए गए विशिष्ट फ़्लोटिंग पॉइंट मान किसी भी समय बदल सकते हैं। उपयोगकर्ताओं को केवल अनुमानित सटीकता और संख्यात्मक स्थिरता पर भरोसा करना चाहिए, गणना की गई विशिष्ट बिट्स पर नहीं। मामूली और पैच रिलीज में संख्यात्मक सूत्रों में परिवर्तन के परिणामस्वरूप तुलनीय या बेहतर सटीकता होनी चाहिए, इस चेतावनी के साथ कि मशीन सीखने में विशिष्ट सूत्रों की सटीकता में सुधार के परिणामस्वरूप समग्र प्रणाली के लिए कम सटीकता हो सकती है।

• यादृच्छिक संख्याएँ: गणना की गई विशिष्ट यादृच्छिक संख्याएँ किसी भी समय बदल सकती हैं। उपयोगकर्ताओं को केवल लगभग सही वितरण और सांख्यिकीय ताकत पर भरोसा करना चाहिए, गणना की गई विशिष्ट बिट्स पर नहीं। विवरण के लिए यादृच्छिक संख्या जनरेशन गाइड देखें।

• वितरित Tensorflow में संस्करण तिरछा: TensorFlow के दो अलग-अलग संस्करणों को एक ही क्लस्टर में चलाना असमर्थित है। वायर प्रोटोकॉल के पश्चगामी संगतता के बारे में कोई गारंटी नहीं है।

• बग: यदि वर्तमान कार्यान्वयन स्पष्ट रूप से टूटा हुआ है, यानी, यदि यह दस्तावेज़ीकरण के विपरीत है या यदि एक प्रसिद्ध और अच्छी तरह से परिभाषित इच्छित व्यवहार उचित रूप से कार्यान्वित नहीं किया गया है, तो हम पिछड़े असंगत व्यवहार (हालांकि एपीआई नहीं) परिवर्तन करने का अधिकार सुरक्षित रखते हैं। एक बग के लिए। उदाहरण के लिए, यदि कोई ऑप्टिमाइज़र एक प्रसिद्ध ऑप्टिमाइज़ेशन एल्गोरिथम को लागू करने का दावा करता है, लेकिन बग के कारण उस एल्गोरिथम से मेल नहीं खाता है, तो हम ऑप्टिमाइज़र को ठीक कर देंगे। हमारा सुधार अभिसरण के लिए गलत व्यवहार पर निर्भर कोड को तोड़ सकता है। हम ऐसे परिवर्तनों को रिलीज़ नोट में नोट करेंगे।

• अप्रयुक्त एपीआई: हम उन एपीआई में पिछड़े असंगत परिवर्तन करने का अधिकार सुरक्षित रखते हैं जिनके लिए हमें कोई प्रलेखित उपयोग नहीं मिला (GitHub खोज के माध्यम से TensorFlow उपयोग का ऑडिट करके)। इस तरह का कोई भी परिवर्तन करने से पहले, हम घोषणा @ मेलिंग सूची में परिवर्तन करने के अपने इरादे की घोषणा करेंगे, किसी भी टूट-फूट (यदि लागू हो) को संबोधित करने के निर्देश प्रदान करेंगे, और अपने समुदाय को अपनी प्रतिक्रिया साझा करने का मौका देने के लिए दो सप्ताह तक प्रतीक्षा करेंगे। .

• त्रुटि व्यवहार: हम त्रुटियों को गैर-त्रुटि व्यवहार से बदल सकते हैं। उदाहरण के लिए, हम त्रुटि उत्पन्न करने के बजाय परिणाम की गणना करने के लिए फ़ंक्शन को बदल सकते हैं, भले ही उस त्रुटि को प्रलेखित किया गया हो। हम त्रुटि संदेशों के पाठ को बदलने का अधिकार भी सुरक्षित रखते हैं। इसके अलावा, त्रुटि का प्रकार तब तक बदल सकता है जब तक कि दस्तावेज़ में किसी विशिष्ट त्रुटि स्थिति के लिए अपवाद प्रकार निर्दिष्ट नहीं किया जाता है।

सहेजे गए मॉडल, ग्राफ और चेकपॉइंट्स की संगतता

TensorFlow प्रोग्राम में इस्तेमाल करने के लिए सेव्डमॉडल पसंदीदा सीरियलाइज़ेशन फ़ॉर्मैट है। सहेजे गए मॉडल में दो भाग होते हैं: एक या अधिक ग्राफ़ GraphDefs और एक चेकपॉइंट के रूप में एन्कोड किए गए। रेखांकन चलाने के लिए ऑप्स के डेटा प्रवाह का वर्णन करता है, और चौकियों में एक ग्राफ में चर के सहेजे गए टेंसर मान होते हैं।

कई TensorFlow उपयोगकर्ता सहेजे गए मॉडल बनाते हैं, और TensorFlow की बाद की रिलीज़ के साथ उन्हें लोड और निष्पादित करते हैं। सेवर के अनुपालन में, TensorFlow के एक संस्करण के साथ लिखे गए SavedModels को उसी प्रमुख रिलीज के साथ TensorFlow के बाद के संस्करण के साथ लोड और मूल्यांकन किया जा सकता है।

हम समर्थित सहेजे गए मॉडलों के लिए अतिरिक्त गारंटी देते हैं। हम एक सहेजे गए मॉडल को कॉल करते हैं जो TensorFlow प्रमुख संस्करण N में केवल गैर-बहिष्कृत, गैर-प्रायोगिक, गैर-संगतता API का उपयोग करके बनाया गया था, जो कि संस्करण N N समर्थित एक सहेजा गया मॉडल है। TensorFlow प्रमुख संस्करण N में समर्थित किसी भी सहेजे गए मॉडल को TensorFlow प्रमुख संस्करण N+1 के साथ लोड और निष्पादित किया जा सकता है। हालाँकि, ऐसे मॉडल को बनाने या संशोधित करने के लिए आवश्यक कार्यक्षमता अब और उपलब्ध नहीं हो सकती है, इसलिए यह गारंटी केवल अपरिवर्तित सहेजे गए मॉडल पर लागू होती है।

हम यथासंभव लंबे समय तक पश्चगामी संगतता बनाए रखने का प्रयास करेंगे, ताकि क्रमबद्ध फ़ाइलें लंबे समय तक उपयोग करने योग्य रहें।

ग्राफडिफ अनुकूलता

रेखांकन को GraphDef प्रोटोकॉल बफर के माध्यम से क्रमबद्ध किया जाता है। ग्राफ़ में पीछे की ओर असंगत परिवर्तनों को सुविधाजनक बनाने के लिए, प्रत्येक GraphDef में TensorFlow संस्करण से अलग एक संस्करण संख्या होती है। उदाहरण के लिए, GraphDef संस्करण 17 ने reciprocal के पक्ष में inv सेशन को हटा दिया। शब्दार्थ हैं:

• TensorFlow का प्रत्येक संस्करण GraphDef संस्करणों के अंतराल का समर्थन करता है। यह अंतराल सभी पैच रिलीज़ में स्थिर रहेगा, और केवल मामूली रिलीज़ में ही बढ़ेगा। GraphDef संस्करण के लिए समर्थन छोड़ना केवल TensorFlow की एक प्रमुख रिलीज़ के लिए होगा (और केवल सहेजे गए मॉडल के लिए गारंटीकृत संस्करण समर्थन के साथ संरेखित)।

• नए बनाए गए ग्राफ़ को नवीनतम GraphDef संस्करण संख्या सौंपी गई है।

• यदि TensorFlow का दिया गया संस्करण किसी ग्राफ़ के GraphDef संस्करण का समर्थन करता है, तो यह उसी व्यवहार के साथ लोड और मूल्यांकन करेगा, जैसा कि TensorFlow संस्करण इसे उत्पन्न करने के लिए उपयोग किया जाता है (फ़्लोटिंग पॉइंट संख्यात्मक विवरण और यादृच्छिक संख्याओं को छोड़कर, जैसा कि ऊपर उल्लिखित है), प्रमुख की परवाह किए बिना टेंसरफ्लो का संस्करण। विशेष रूप से, एक ग्राफडिफ जो TensorFlow के एक संस्करण में एक चेकपॉइंट फ़ाइल के साथ संगत है (जैसे कि सेव्डमॉडल में मामला है) बाद के संस्करणों में उस चेकपॉइंट के साथ संगत रहेगा, जब तक कि ग्राफडिफ समर्थित है।

  ध्यान दें कि यह केवल ग्राफडिफ्स (और सेवमॉडल्स) में क्रमबद्ध ग्राफ़ पर लागू होता है: कोड जो एक चेकपॉइंट को पढ़ता है, उसी कोड द्वारा उत्पन्न चेकपॉइंट्स को पढ़ने में सक्षम नहीं हो सकता है जो TensorFlow के एक अलग संस्करण को चला रहा है।

• यदि किसी (मामूली) रिलीज़ में GraphDef ऊपरी सीमा को X तक बढ़ा दिया जाता है, तो कम से कम छह महीने पहले निचली सीमा को X तक बढ़ा दिया जाएगा। उदाहरण के लिए (हम यहां काल्पनिक संस्करण संख्याओं का उपयोग कर रहे हैं):

  • TensorFlow 1.2 GraphDef संस्करण 4 से 7 का समर्थन कर सकता है।
  • TensorFlow 1.3 GraphDef संस्करण 8 जोड़ सकता है और संस्करण 4 से 8 का समर्थन कर सकता है।
  • कम से कम छह महीने बाद, TensorFlow 2.0.0 केवल संस्करण 8 को छोड़कर संस्करण 4 से 7 के लिए समर्थन छोड़ सकता है।

  ध्यान दें कि क्योंकि TensorFlow के प्रमुख संस्करणों को आम तौर पर 6 महीने से अधिक समय के अंतराल पर प्रकाशित किया जाता है, ऊपर वर्णित समर्थित सहेजे गए मॉडलों की गारंटी ग्राफ़डिफ़्स के लिए 6 महीने की गारंटी से कहीं अधिक मजबूत होती है।

अंत में, जब किसी GraphDef संस्करण के लिए समर्थन छोड़ दिया जाता है, तो हम ग्राफ़ को एक नए समर्थित GraphDef संस्करण में स्वचालित रूप से परिवर्तित करने के लिए उपकरण प्रदान करने का प्रयास करेंगे।

TensorFlow का विस्तार करते समय ग्राफ़ और चेकपॉइंट संगतता

यह अनुभाग केवल तभी प्रासंगिक है जब GraphDef प्रारूप में असंगत परिवर्तन किए जा रहे हों, जैसे कि ऑप्स जोड़ते समय, ऑप्स हटाते समय या मौजूदा ऑप्स की कार्यक्षमता को बदलते समय। पिछला खंड अधिकांश उपयोगकर्ताओं के लिए पर्याप्त होना चाहिए।

पिछड़े और आंशिक आगे अनुकूलता

हमारी वर्जनिंग स्कीम की तीन आवश्यकताएं हैं:

• TensorFlow के पुराने संस्करणों के साथ बनाए गए लोडिंग ग्राफ़ और चौकियों का समर्थन करने के लिए पश्चगामी संगतता ।
• उन परिदृश्यों का समर्थन करने के लिए अग्रेषित संगतता जहां एक ग्राफ या चेकपॉइंट के निर्माता को उपभोक्ता से पहले TensorFlow के नए संस्करण में अपग्रेड किया जाता है।
• TensorFlow को असंगत तरीकों से विकसित करने में सक्षम करें। उदाहरण के लिए, ऑप्स को हटाना, विशेषताएँ जोड़ना और विशेषताओं को हटाना।

ध्यान दें कि हालांकि GraphDef संस्करण तंत्र TensorFlow संस्करण से अलग है, GraphDef प्रारूप में पिछड़े असंगत परिवर्तन अभी भी सिमेंटिक वर्जनिंग द्वारा प्रतिबंधित हैं। इसका मतलब है कि कार्यक्षमता को केवल TensorFlow के MAJOR संस्करणों (जैसे 1.7 से 2.0 ) के बीच हटाया या बदला जा सकता है। इसके अतिरिक्त, पैच रिलीज़ (उदाहरण के लिए 1.x.1 से 1.x.2 ) के भीतर अग्रेषित संगतता लागू की जाती है।

पिछड़े और आगे की अनुकूलता प्राप्त करने के लिए और यह जानने के लिए कि स्वरूपों में परिवर्तनों को कब लागू करना है, ग्राफ़ और चौकियों में मेटाडेटा होता है जो वर्णन करता है कि वे कब बनाए गए थे। नीचे दिए गए अनुभाग TensorFlow के कार्यान्वयन और GraphDef संस्करणों को विकसित करने के लिए दिशानिर्देशों का विवरण देते हैं।

स्वतंत्र डेटा संस्करण योजनाएं

रेखांकन और चौकियों के लिए अलग-अलग डेटा संस्करण हैं। दो डेटा प्रारूप एक दूसरे से अलग दरों पर और TensorFlow से अलग दरों पर विकसित होते हैं। दोनों वर्जनिंग सिस्टम को core/public/version.h में परिभाषित किया गया है। जब भी कोई नया संस्करण जोड़ा जाता है, तो हेडर में एक नोट जोड़ा जाता है जिसमें यह बताया जाता है कि क्या बदला और तारीख क्या है।

डेटा, निर्माता और उपभोक्ता

हम निम्न प्रकार की डेटा संस्करण जानकारी के बीच अंतर करते हैं:

• निर्माता : बायनेरिज़ जो डेटा उत्पन्न करते हैं। उत्पादकों के पास एक संस्करण ( producer ) और एक न्यूनतम उपभोक्ता संस्करण होता है जिसके साथ वे संगत होते हैं ( min_consumer )।
• उपभोक्ता : बायनेरिज़ जो डेटा का उपभोग करते हैं। उपभोक्ताओं के पास एक संस्करण ( consumer ) और एक न्यूनतम निर्माता संस्करण होता है जिसके साथ वे संगत होते हैं ( min_producer )।

वर्जन किए गए डेटा के प्रत्येक भाग में एक VersionDef versions फील्ड होता है जो उस producer को रिकॉर्ड करता है जिसने डेटा बनाया है, min_consumer जिसके साथ यह संगत है, और bad_consumers संस्करणों की एक सूची है जो अस्वीकृत हैं।

डिफ़ॉल्ट रूप से, जब कोई निर्माता कुछ डेटा बनाता है, तो डेटा निर्माता के producer और min_consumer संस्करणों को इनहेरिट करता है। bad_consumers सेट किया जा सकता है यदि विशिष्ट उपभोक्ता संस्करणों में बग शामिल हैं और इससे बचा जाना चाहिए। एक उपभोक्ता डेटा का एक टुकड़ा स्वीकार कर सकता है यदि निम्नलिखित सभी सत्य हैं:

• consumer > = डेटा का min_consumer
• डेटा का producer > = उपभोक्ता का min_producer
• consumer डेटा के bad_consumers में नहीं है

चूंकि निर्माता और उपभोक्ता दोनों एक ही TensorFlow कोड बेस से आते हैं, core/public/version.h वर्जन.एच में एक मुख्य डेटा संस्करण होता है जिसे संदर्भ के आधार पर या तो producer या consumer के रूप में माना जाता है और दोनों min_consumer और min_producer (क्रमशः उत्पादकों और उपभोक्ताओं द्वारा आवश्यक) . विशेष रूप से,

• GraphDef संस्करणों के लिए, हमारे पास TF_GRAPH_DEF_VERSION , TF_GRAPH_DEF_VERSION_MIN_CONSUMER , और TF_GRAPH_DEF_VERSION_MIN_PRODUCER ।
• चेकपॉइंट संस्करणों के लिए, हमारे पास TF_CHECKPOINT_VERSION , TF_CHECKPOINT_VERSION_MIN_CONSUMER , और TF_CHECKPOINT_VERSION_MIN_PRODUCER ।

किसी मौजूदा ऑप में डिफ़ॉल्ट के साथ एक नई विशेषता जोड़ें

नीचे दिए गए मार्गदर्शन का पालन करने से आपको केवल तभी अनुकूलता मिलती है जब ऑप्स का सेट नहीं बदला हो:

1. यदि आगे संगतता वांछित है, तो tf.saved_model.SavedModelBuilder.add_meta_graph_and_variables और tf.saved_model.SavedModelBuilder.add_meta_graph विधियों या SavedModelBuilder का उपयोग करके मॉडल को निर्यात करते समय strip_default_attrs को True पर सेट करें tf.estimator.Estimator.export_saved_model
2. यह मॉडल के उत्पादन/निर्यात के समय डिफ़ॉल्ट मूल्यवान विशेषताओं को हटा देता है। यह सुनिश्चित करता है कि निर्यात किए गए tf.MetaGraphDef में डिफ़ॉल्ट मान का उपयोग होने पर नया op-विशेषता शामिल नहीं है।
3. इस नियंत्रण के होने से पुराने उपभोक्ता (उदाहरण के लिए, सेवारत बायनेरिज़ जो प्रशिक्षण बायनेरिज़ से पिछड़ जाते हैं) को मॉडल लोड करना जारी रखने और मॉडल प्रस्तुति में रुकावटों को रोकने की अनुमति मिल सकती है।

विकासशील ग्राफडिफ संस्करण

यह खंड बताता है कि इस वर्जनिंग मैकेनिज्म का उपयोग GraphDef प्रारूप में विभिन्न प्रकार के परिवर्तन करने के लिए कैसे करें।

एक ऑप जोड़ें

एक ही समय में उपभोक्ताओं और उत्पादकों दोनों के लिए नया ऑप जोड़ें, और किसी भी GraphDef संस्करण को न बदलें। इस प्रकार का परिवर्तन स्वचालित रूप से पिछड़ा संगत है, और आगे की संगतता योजना को प्रभावित नहीं करता है क्योंकि मौजूदा निर्माता स्क्रिप्ट अचानक नई कार्यक्षमता का उपयोग नहीं करेगी।

एक ऑप जोड़ें और इसका उपयोग करने के लिए मौजूदा पायथन रैपर को स्विच करें

1. नई उपभोक्ता कार्यक्षमता लागू करें और GraphDef संस्करण बढ़ाएँ।
2. यदि यह संभव है कि रैपर नई कार्यक्षमता का उपयोग केवल उन मामलों में करें जो पहले काम नहीं करते थे, तो रैपर को अब अपडेट किया जा सकता है।
3. नई कार्यक्षमता का उपयोग करने के लिए पायथन रैपर बदलें। min_consumer में वृद्धि न करें, क्योंकि जो मॉडल इस ऑप का उपयोग नहीं करते हैं उन्हें टूटना नहीं चाहिए।

किसी ऑप की कार्यक्षमता को निकालें या प्रतिबंधित करें

1. प्रतिबंधित ऑप या कार्यक्षमता का उपयोग न करने के लिए सभी निर्माता स्क्रिप्ट (स्वयं TensorFlow नहीं) को ठीक करें।
2. GraphDef संस्करण को बढ़ाएँ और नई उपभोक्ता कार्यक्षमता को लागू करें जो ग्राफ़डिफ़्स के लिए हटाए गए ऑप या कार्यक्षमता को नए संस्करण और इसके बाद के संस्करण पर प्रतिबंधित करता है। यदि संभव हो, तो TensorFlow को प्रतिबंधित कार्यक्षमता वाले GraphDefs का उत्पादन बंद करने दें। ऐसा करने के लिए, REGISTER_OP(...).Deprecated(deprecated_at_version, message) जोड़ें।
3. पिछड़े अनुकूलता उद्देश्यों के लिए एक बड़ी रिलीज की प्रतीक्षा करें।
4. (2) से min_producer को ग्राफ़डिफ़ संस्करण में बढ़ाएँ और कार्यक्षमता को पूरी तरह से हटा दें।

एक सेशन की कार्यक्षमता बदलें

1. SomethingV2 या समान नाम से एक नया समान ऑप जोड़ें और इसे जोड़ने की प्रक्रिया से गुजरें और इसका उपयोग करने के लिए मौजूदा पायथन रैपर को स्विच करें। आगे की संगतता सुनिश्चित करने के लिए पायथन रैपर को बदलते समय compat.py में सुझाए गए चेक का उपयोग करें।
2. पुराने ऑप को हटाएं (पिछड़ी संगतता के कारण केवल एक प्रमुख संस्करण परिवर्तन के साथ ही हो सकता है)।
3. पुराने ऑप के साथ उपभोक्ताओं को हटाने के लिए min_consumer बढ़ाएं, पुराने ऑप को SomethingV2 2 के लिए उपनाम के रूप में वापस जोड़ें, और इसका उपयोग करने के लिए मौजूदा पायथन रैपर को स्विच करने की प्रक्रिया से गुजरें।
4. SomethingV2 को हटाने के लिए प्रक्रिया से गुजरें।

एकल असुरक्षित उपभोक्ता संस्करण पर प्रतिबंध लगाएं

1. सभी नए ग्राफडिफ्स के लिए GraphDef संस्करण को टक्कर दें और खराब संस्करण को bad_consumers में जोड़ें। यदि संभव हो, तो bad_consumers में केवल bad_consumers के लिए जोड़ें, जिसमें एक निश्चित ऑप या समान शामिल है।
2. यदि मौजूदा उपभोक्ताओं के पास खराब संस्करण है, तो उन्हें जल्द से जल्द बाहर कर दें।