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

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

शब्दार्थ २.०

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

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

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

  • पैटर्न : पीछे संगत बग फिक्स।

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

क्या कवर किया गया है

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

  • सिवाय इसके कि tensorflow मॉड्यूल और उसके tensorflow में सभी दस्तावेज पायथन फ़ंक्शन और कक्षाएं

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

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

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

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

  • सी एपीआई

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

जो ढंका नहीं है

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

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

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

    • कोई भी प्रतीक जिसका पूरी तरह से योग्य नाम में एक मॉड्यूल या वर्ग शामिल है जो स्वयं प्रयोगात्मक है। इसमें experimental कहे जाने वाले किसी भी प्रोटोकॉल बफर के फ़ील्ड और सबमेस शामिल हैं।

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

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

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

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

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

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

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

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

SavedModels, रेखांकन और चौकियों की संगतता

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

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

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

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

ग्राफडिफ़ संगतता

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

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

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

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

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

  • यदि GraphDef ऊपरी बाध्य एक (छोटे) विज्ञप्ति में एक्स तक बढ़ जाती है, वहां कम से कम छह महीने पहले लोअर बाउंड उदाहरण के लिए एक्स (हम काल्पनिक संस्करण संख्याओं यहाँ का उपयोग कर रहे) तक बढ़ जाती है हो जाएगा:

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

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

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

TensorFlow का विस्तार करते समय ग्राफ़ और चौकी की संगतता

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

पिछड़े और आंशिक आगे संगतता

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

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

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

ग्राफडिफ संस्करणों का विकास

यह अनुभाग बताता है कि GraphDef प्रारूप में विभिन्न प्रकार के परिवर्तन करने के लिए इस संस्करण तंत्र का उपयोग कैसे किया GraphDef

एक सेशन जोड़ें

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

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

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

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

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

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

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

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

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