आंतरिक उपयोगिता के पुराने संस्करण के बारे में चेतावनी कैसे दें

इस स्थिति की कल्पना करें:

• हमारे पास एक आंतरिक उपयोगिता है (कहते हैं, एक स्तर संपादक)। समय-समय पर नए संस्करण जारी किए जाते हैं।
• जानकारी XML या किसी अन्य ट्री-जैसे एक्स्टेंसिबल प्रारूप में संग्रहीत की जाती है। उसी समय, हम, प्रकाश जेडी के रूप में, नीचे से ऊपर की ओर से संगतता की निगरानी करते हैं, और बाद के संस्करण सभी प्रारंभिक परियोजनाओं को खोलते हैं।
• उपयोगिता का उपयोग उन लोगों द्वारा किया जाता है जो तकनीकी नहीं हैं और "प्रारंभिक अनुकरण सिंड्रोम" के अधीन नहीं हैं। उनके पास संपादक का नवीनतम संस्करण नहीं है; मुख्य बात एक परियोजना के ढांचे के भीतर स्थिर और समान है।
• नए फ़ंक्शन समय-समय पर दिखाई देते हैं, इन कार्यों के लिए XML में नए ब्लॉक दिखाई देते हैं। इसी समय, यह स्थिति संभव है: एक परियोजना पर दो काम करने दें। एक कार्यक्रम नए ब्लॉकों का समर्थन करता है, जबकि दूसरा नहीं करता है। परियोजना को बचाने वाला दूसरा, इन ब्लॉकों को खो देगा।
• कभी-कभी आपको डेटा स्टोरेज फॉर्मेट को "रिड्रा" करना होता है। उदाहरण के लिए, पहले एक टाइलसेट था - अब एक पूरा गुच्छा। पुराने संस्करण, सबसे अधिक संभावना है, "छत को उड़ाएगा", और डाउनलोड करने से पहले चेतावनी दी जानी चाहिए: "यह नए संस्करण से एक बचत है और, सबसे अधिक संभावना है, असंगत। डाउनलोड जारी रखें? ”
• यदि हम एक पुराने प्रोजेक्ट को नए संस्करण के साथ खोलते हैं, तो इसी तरह की पुष्टि की आवश्यकता है उपयोगिता अभी भी आंतरिक है, और आपको इसमें रिकॉर्डिंग के लिए पुराने बचत के समर्थन को संरक्षित नहीं करना चाहिए।
• चूंकि उपयोगिता आंतरिक है, इसलिए यह "कुछ नहीं की तुलना में बीटा" है, और इसकी अखंडता की कमी की एकमात्र गारंटी हमारा व्यावसायिकता है। कभी-कभी "ब्लैक" संस्करण दिखाई देते हैं जो डेटा को खराब करते हैं। डिजाइनर को कैसे चेतावनी दें कि उसके संस्करण में एक बुरा गलती हुई है?
• आपको एक केंद्रीकृत अपडेट सर्वर के बिना करने की आवश्यकता है।

मैं 2005 में इस सरल समाधान के साथ आया, मोबाइल गेम पर काम कर रहा था, ताकि किसी तरह चिड़ियाघर संस्करणों के साथ सामना कर सके।

हम प्रत्येक दस्तावेज़ में चार फ़ील्ड संग्रहीत करते हैं।

• BuildSaved - वह संस्करण जिसे हमने प्रोजेक्ट को सहेजा है।
• BuildSupported - सबसे छोटा संस्करण जो इस गेम को पूरी तरह से खोलने की गारंटी है।
• BuildRequired - सबसे छोटा संस्करण, जो कम से कम आंशिक रूप से, लेकिन त्रुटियों के बिना, इस गेम को बचाएगा।
• BlackBuilds - सभी संस्करण जो डेटा को दूषित करते हैं।

उसी समय, BuildSaved> = BuildSupported> = BuildRequired। मैंने संस्करण संख्याओं को स्रोत में कठिन रूप से सेट किया है। XML में एक नया फ़ील्ड दिखाई दिया है - BuildSupported को वर्तमान संस्करण के साथ बदलें। स्टोरेज फॉर्मेट को रीडिड करें - BuildSupported और BuildRequired को तुरंत बदलें। BlackBuilds ने सटिक रूप से, चैंज के द्वारा निर्धारित किया - उस संस्करण से जिसमें त्रुटिपूर्ण कार्यक्षमता दिखाई दी, जिस पर उन्होंने ध्यान दिया और ठीक किया।

दस्तावेज खोलते हुए, हम ऐसे चेक करते हैं।

• यदि प्रोग्राम का वर्तमान संस्करण BuildRequired की तुलना में कम है, तो हम सूचित करते हैं: “यह नए संस्करण से एक दस्तावेज़ है और, सबसे अधिक संभावना है, असंगत है। डाउनलोड जारी रखें? ”
• यदि संस्करण BuildSupported से कम है, तो हम सूचित करते हैं: "दस्तावेज़ में नए फ़ील्ड हो सकते हैं जो फिर से सहेजने पर खो जाएंगे।"
• यदि संस्करण BlackBuilds में से एक है, तो हम सूचित करते हैं: “आपका संस्करण दस्तावेजों को खराब करता है। कुछ भी न बचाएं, कम खतरनाक संस्करण में अपग्रेड करें। ”
• अगर BuildSaved EXE फ़ाइल में संग्रहीत "ब्लैक" संस्करणों में से एक है, तो हम आउटपुट: "दस्तावेज़ को एक खतरनाक संस्करण द्वारा सहेजा गया था। दस्तावेज़ में त्रुटियाँ हो सकती हैं। दस्तावेज़ को सहेजने वाले को तुरंत अपडेट होने दें। ”
• अंत में, यदि एक पुरानी डेटा स्टोरेज मैकेनिज्म का पता चलता है, तो हम आउटपुट करते हैं: "इससे पहले कि आप दोबारा सेव करें, बैकअप कॉपी बना लें।" बेहतर अभी तक, स्वचालित रूप से एक बैकअप बनाएं (सुझाव दिया जाए)। पहले से ही एक बिल्डअर्सिफाइड अंक के आधार पर कोई भी नंगे विवरण नहीं हैं: हम देखते हैं कि प्रारूप लोड होने या न होने पर खुद को लोड करते हैं।