ऐप स्टोर रिलीज़ पर कौन से iOS ऐप वर्जन / बिल्ड नंबर (नंबर) जरूरी होने चाहिए?


107

IOS ऐप के लिए संस्करण / बिल्ड फ़ील्ड में शामिल हैं:

  • "संस्करण" CFBundleShortVersionString (स्ट्रिंग - iOS, OS X) बंडल के रिलीज़ संस्करण की संख्या को निर्दिष्ट करता है, जो ऐप के रिलीज़ किए गए पुनरावृत्ति की पहचान करता है। रिलीज़ संस्करण संख्या एक स्ट्रिंग है जिसमें तीन अवधि-पृथक पूर्णांक शामिल हैं।

  • "बिल्ड" CFBundleVersion (स्ट्रिंग - आईओएस, ओएस एक्स) बंडल के बिल्ड संस्करण संख्या को निर्दिष्ट करता है, जो बंडल के एक पुनरावृत्ति (जारी या अप्रकाशित) की पहचान करता है। बिल्ड संस्करण संख्या में एक स्ट्रिंग होनी चाहिए जिसमें तीन गैर-ऋणात्मक, अवधि-पूर्ण पूर्णांक पूर्णांक पूर्णांक शून्य से अधिक हो। स्ट्रिंग में केवल संख्यात्मक (0-9) और अवधि (।) अक्षर होने चाहिए। अग्रणी शून्य को प्रत्येक पूर्णांक से काट दिया जाता है और इसे अनदेखा किया जाएगा (अर्थात 1.02.3 1.2.3 के बराबर है)। यह कुंजी स्थानीय नहीं है।

  • "आईट्यून्स कनेक्ट वर्जन संख्या" : आईट्यून्स कनेक्ट पर ऐप का नया संस्करण बनाते समय आपके द्वारा निर्दिष्ट संस्करण संख्या।

मेरा सवाल यह है कि:

जब ऐप के नए संस्करण को आईट्यून्स कनेक्ट और / या ऐप स्टोर पर जारी किया जाता है, तो कौन से संस्करण / बिल्ड नंबर को बढ़ाना आवश्यक है ?

ऐप अपडेट्स के बीच "वर्जन" CFBundleShortVersionStringया "बिल्ड" CFBundleVersionदोनों समान रह सकते हैं?

Apple स्रोतों या सटीक त्रुटि संदेशों के लिए अतिरिक्त बिंदु iTunesConnect एक अमान्य संस्करण / बिल्ड नंबर अपलोड करने पर प्रदर्शित करता है।


Android / Google Play नोट:

इस प्रश्न पर चर्चा करने का विषय यह है कि Google Play Store में Android एप्लिकेशन के सार्वजनिक "संस्करण" को बढ़ाने की आवश्यकता नहीं है और यह किसी भी तरह से मान्य नहीं है। android:versionName, विज्ञप्ति के बीच ही रहते हैं कर सकते हैं उन्नयन, ढाल, या बजाय किसी भी यादृच्छिक स्ट्रिंग कुछ है कि प्रकट होता है एक वैध "संस्करण संख्या" होने के लिए।

android:versionName - एक स्ट्रिंग मान जो एप्लिकेशन कोड के रिलीज़ संस्करण का प्रतिनिधित्व करता है, क्योंकि इसे उपयोगकर्ताओं को दिखाया जाना चाहिए।

मान एक स्ट्रिंग है ताकि आप एप्लिकेशन संस्करण को <major>.<minor>.<point>स्ट्रिंग के रूप में , या किसी अन्य प्रकार के निरपेक्ष या सापेक्ष संस्करण पहचानकर्ता के रूप में वर्णन कर सकें ।

Android में versionName और versionNumber के बीच अंतर

जबकि android:versionCodeएक वृद्धि पर जारी पूर्णांक होने के लिए लागू किया जाता है।


Apple प्रलेखन

जैसा कि नव स्वीकृत उत्तर में उल्लेख किया गया है , Apple ने हाल ही में एक तकनीकी नोट प्रकाशित किया है जो उनके संस्करण का विवरण देता है और संख्या योजना का निर्माण करता है:

Apple तकनीकी नोट TN2420 - संस्करण संख्याएँ और संख्याएँ बनाएँ


स्क्रीनशॉट के साथ एक विस्तृत जवाब: stackoverflow.com/a/31921249/936957
यूनुस नेदिम मेहल

जवाबों:


115

Apple टेक्निकल नोट TN2420, वर्जन नंबर और बिल्ड नंबर

सारांश:

  • जोड़ी ( Version, Build number) अद्वितीय होनी चाहिए।
    • अनुक्रम मान्य है: (1.0.1, 12) -> (1.0.1, 13) -> (1.0.2, 13) -> (1.0.2, 14) ...
  • Version( CFBundleShortVersionString ) क्रमिक क्रम में आरोही होना चाहिए।
  • Build number( CFBundleVersion ) आरोही क्रम में होना चाहिए।

वर्जन नंबर और बिल्ड नंबर चेकलिस्ट

यहां कुछ चीजें दी गई हैं जिन्हें आप ऐप स्टोर में एक नया बिल्ड सबमिट करते समय देख सकते हैं। सुनिश्चित करें कि आपके पास अपना संस्करण संख्या और बिल्ड नंबर ठीक से सेट है, अनुचित तरीके से कॉन्फ़िगर किए गए अपने ऐप को स्वचालित रूप से अस्वीकार करने से बचने में आपकी सहायता करेगा।

  1. अपने ऐप के प्रत्येक नए संस्करण के लिए, आपको एक नया संस्करण नंबर आविष्कार करना होगा। यह संख्या आपके द्वारा उपयोग किए जाने वाले अंतिम संस्करण की संख्या से अधिक मूल्य की होनी चाहिए। यद्यपि आप अपने ऐप की किसी विशेष रिलीज़ के लिए कई बिल्ड प्रदान कर सकते हैं, आपको केवल अपने ऐप के प्रत्येक नए रिलीज़ के लिए एक नए संस्करण संख्या का उपयोग करने की आवश्यकता है।
  2. आप संस्करण संख्याओं का फिर से उपयोग नहीं कर सकते।
  3. आपके द्वारा सबमिट किए गए प्रत्येक नए बिल्ड के लिए, आपको एक नए बिल्ड नंबर का आविष्कार करना होगा, जिसका मूल्य आपके द्वारा उपयोग किए गए अंतिम बिल्ड नंबर (उस संस्करण के लिए) से अधिक है।
  4. आप विभिन्न रिलीज़ ट्रेनों में बिल्ड नंबरों का फिर से उपयोग कर सकते हैं, लेकिन आप उसी रिलीज़ ट्रेन के भीतर बिल्ड नंबरों का फिर से उपयोग नहीं कर सकते। MacOS ऐप्स के लिए, आप किसी भी रिलीज़ ट्रेन में बिल्ड नंबरों का फिर से उपयोग नहीं कर सकते हैं।

चेकलिस्ट के आधार पर, निम्नलिखित (Version, Build Number)अनुक्रम भी मान्य है।

  • मामला: Build Numberविभिन्न रिलीज़ ट्रेनों में पुन: उपयोग (नोट: नहीं macOS ऐप)

    (1.0.0, 1) -> (1.0.0, 2) -> ... -> (1.0.0, 11) -> ( 1.0.1 , 1 ) -> (1.0.1, 2)


मैं उलझन में हूं। शर्तों में से एक है "आप संस्करण संख्याओं का फिर से उपयोग नहीं कर सकते हैं," लेकिन अंतिम उदाहरण में, संस्करण संख्याएं समान हैं जबकि बिल्ड संख्याएं बढ़ रही हैं। क्या मैं कुछ गलत कर रहा हूँ?
एमिल

@ ईमिल, मुझे लगता है कि यह (संस्करण, बिल्ड नंबर) जोड़ी का पुन: उपयोग नहीं किया जा सकता है।
एचिओलियू

6
@EmilParikh संस्करण संख्या को रिलीज़ से पहले Apple गुणकों पर अपलोड किया जा सकता है , प्रत्येक एक अद्वितीय बिल्ड नंबर के साथ। लेकिन एक बार यह जारी हो जाने के बाद, आप उस संस्करण संख्या का पुन: उपयोग नहीं कर सकते।
pkamb

1
TN2420 का कहना है कि "संस्करण संख्या और बिल्ड संख्या में समयावधि द्वारा अलग किए गए तीन घटक हो सकते हैं " और फिर निम्नलिखित अवैध उदाहरण प्रदान करता है 1.10000.1.5 । हालाँकि यह कई ऐप्स की तरह दिखता है, जिसमें क्रोम एक वर्जन नंबर का उपयोग करता है जिसमें 4 घटक होते हैं (उदाहरण 68.0.3440.83 )। मुझे लगता है कि यह इस तथ्य से समझाया जा सकता है कि TN2420 पृष्ठ में उल्लेख किया गया है " महत्वपूर्ण: यह दस्तावेज़ अब अपडेट नहीं किया जा रहा है। " हालांकि, मैं नए नियमों को परिभाषित करने वाले अद्यतन डॉक्टर को खोजने में सक्षम नहीं हूं। किसी और को भ्रमित किया?
कैटैनमैन

@ कैटनमैन मुझे यह शब्दार्थ संस्करण पसंद है । वर्जन (major, minor, patch)ढंग से बनाएं। और मैंने पहले 4 घटकों का उपयोग किया था, लेकिन ऐप स्टोर 4 घटकों के साथ उस प्रारूप को स्वीकार नहीं करता है।
एकोएलियू

38

CFBundleShortVersionStringसंस्करण संख्या आप iTunes कनेक्ट देना मेल खाना चाहिए। यह वह वर्जन नंबर भी है जो ऐप स्टोर में यूजर को आपके ऐप पर दिखता है।

संस्करण संख्या को स्टोर में दिखाया गया है और उस संस्करण को उस संस्करण संख्या से मेल खाना चाहिए जिसे आप बाद में आईट्यून्स कनेक्ट में दर्ज करते हैं।

स्रोत

CFBundleVersionApp स्टोर में प्रदर्शित नहीं किया जाता है लेकिन यह पता करने के लिए जब अपने अनुप्रयोग अद्यतन किया गया है आईट्यून द्वारा प्रयोग किया जाता है।

यदि आप बिल्ड स्ट्रिंग को अपडेट करते हैं, जैसा कि "संस्करण संख्या और बिल्ड स्ट्रिंग सेट करना" में वर्णित है, तो iTunes यह मानता है कि बिल्ड स्ट्रिंग बदल गई है और उपकरणों का परीक्षण करने के लिए नए iOS ऐप स्टोर पैकेज को ठीक से सिंक करती है।

स्रोत

आपके प्रश्नों का उत्तर विशेष रूप से ...

जब ऐप के नए संस्करण को ऐप स्टोर पर अपलोड किया जाता है तो कौन से संस्करण / बिल्ड नंबर को बढ़ाना आवश्यक है?

दोनों। एक ऐप स्टोर में प्रदर्शित किया गया है, दूसरा ऐप को अपडेट करने के लिए आईट्यून्स द्वारा उपयोग किया जाता है।

या तो CFBundleShortVersionString या CFBundleVersion ऐप अपडेट के बीच एक ही रह सकता है?

नहीं। (मेटा प्रश्न, यहां उपयोग का मामला क्या होगा? यदि आपने किसी भी तरह से पेलोड को संपादित किया है, तो निर्माण अलग होगा, और उपयोगकर्ता इसके बारे में जानना चाहेंगे)। यदि आप प्रयास करते हैं, तो आपको नीचे की तरह त्रुटि संदेश दिखाई देंगे:

त्रुटि संदेश

या क्या वे यह सुनिश्चित करने के लिए पिछले संबंधित संख्या की तुलना में हैं कि ऐप के नए संस्करण के साथ संख्यात्मक रूप से अधिक संख्या अपलोड की गई है?

हाँ। Semver.org मानक का उपयोग करना ।

क्या CFBundleShortVersionString और CFBundleVersion नंबर एक दूसरे की तुलना में किसी भी तरह से हैं?

नहीं।


2
सही, मुझे पता है कि दो नंबरों का उपयोग कैसे किया जाता है। सवाल यह है कि क्या ऐप के नए संस्करण को जारी करते समय दोनों को बढ़ाना आवश्यक है?
pkamb

2
हां, यदि आप दोनों को अपडेट किए बिना किसी ऐप को ऐप स्टोर में धकेलने का प्रयास करते हैं, तो आपको एक त्रुटि संदेश दिखाई देगा, जैसे stackoverflow.com/questions/19367893/…
एंडी

धन्यवाद, महान संपादित करें। खासकर उस लिंक के लिए। आयोजक के सत्यापनकर्ता दिखा रहा है "CFBundleVersion और CFBundleShortVersionString दोनों के लिए उच्च संस्करण में" त्रुटियाँ होनी चाहिए "।
pkamb

1
+1 वीर्य लिंक के लिए ... एक संस्करण संख्या MAJOR.MINOR.PATCH को देखते हुए, वृद्धि: MAJOR संस्करण जब आप असंगत एपीआई परिवर्तन करते हैं, तो जब आप पीछे की ओर संगत तरीके से कार्यक्षमता जोड़ते हैं, तो MINOR संस्करण, और जब आप पीछे की तरफ संस्करण बनाते हैं। - असंगत बग फिक्स।
jeet.chanchawat

इस बारे में: यहां उपयोग का मामला क्या होगा? यदि आपने किसी भी तरह से पेलोड को संपादित किया है, तो निर्माण अलग होगा, और उपयोगकर्ता इसके बारे में जानना चाहेंगे । मेरा उपयोग मामला यह है कि मेरा ऐप Apple द्वारा सफल रहा, लेकिन ऐप स्टोर में इससे पहले कभी रिलीज़ नहीं हुआ। मुझे एक त्रुटि मिली और मैं इसे बगिंक करना चाहता हूं - बिना बदले CFBundleShortVersionString। क्या यह संभव है? मैं अपने खुद के ऐप को अस्वीकार करना चाहता हूं।
परीक्षण

31

CFBundleShortVersionString संस्करण का सार्वजनिक "नाम" है (उदाहरण: "2.5", या "3.8.1%")। आपको प्रत्येक रिलीज़ पर इसे बढ़ाना होगा ।

CFBundleVersion निजी बिल्ड नंबर है। यह AppStore पर नहीं देखा जाता है। आपको प्रत्येक अपलोड पर इसे बढ़ाना होगा । इसका मतलब है कि यदि आप ऑनलाइन जाने से पहले कभी भी किसी बाइनरी को अस्वीकार करते हैं, और आप एक नया बाइनरी अपलोड करना चाहते हैं, तो इसमें एक ही CFBundleShortVersionString होगा लेकिन एक उच्च CFBundleVersion (उदाहरण: सार्वजनिक) "2.5", निजी "2.5" और फिर होना चाहिए बाइनरी अस्वीकार, और फिर से अपलोड निजी "2.5.1")

16 नवंबर 2016 को संपादित करें:

/ ! \ CFBundleVersion संपत्ति भी (के साथ प्रयोग किया जाता है CFBundleName में) User-Agentद्वारा भेजे गए हेडर NSURLConnection अपने कोड में।

उदाहरण: यदि CFBundleName है MyApp और CFBundleVersion 2.21 है, तो किसी भी कार्यक्रम संबंधी HTTP क्वेरी अपने कोड का उपयोग करके सीधे भेजा NSURLConnection हैडर एम्बेड कर देंगे:

User-Agent: MyApp/2.21 CFNetwork/... Darwin/...

(यह UIWebView द्वारा स्वचालित रूप से जारी किए गए अनुरोधों पर लागू नहीं होता है)।


2
अपलोड / रिलीज के लिए आवश्यकताओं के बीच बड़ा अंतर।
18

@ गैब्रिएल, मैंने बिल्ड नंबर को XX-rc2 में सेट करने की कोशिश की है, लेकिन ऑर्गनाइज़र वैलिडेटर मुझे XYZ से अलग कुछ भी सेट करने की अनुमति नहीं देता है जहाँ X, Y और Z पूर्णांक हैं: S। A -rc2 बिल्ड नंबर होना बहुत अच्छा होगा, क्या आप कभी इसके साथ एक रिलीज़ सबमिट कर पाए हैं?
नेस्टॉर

1
@ नोस्टर तुम सही हो, मैं गलत था। केवल संख्या की अनुमति है। मुझे अपना उत्तर संपादित करने दें।
गैब्रियल

@gabriel, मैं iTunes स्क्रिप्ट को अपलोड करने के लिए जनरेट करने के लिए CI सिस्टम के लिए पार्स X.X-rc2टू X.X.2, स्क्रिप्ट का उपयोग करता buildNumberहूं।
अचोलिउ

5

CFBundleVersion और CFBundleShortVersionString ऐप के अंतिम संस्करण की संख्या से अधिक होना चाहिए। उन्हें समान रखना एक अच्छा अभ्यास है। आपको उन्हें अपने -info.plist में ढूंढना चाहिए।

जब आप आयोजक में एप्लिकेशन को मान्य करने का प्रयास करते हैं तो यह एक त्रुटि फेंक देगा यदि उनमें से किसी को भी नहीं बढ़ाया गया है। कल रात मेरे पास आया।


मैंने अपने प्रश्न में उन दोनों कुंजियों का उल्लेख किया है। क्या आपका जवाब यहाँ है कि उन दोनों मूल्यों को बढ़ाया जाना चाहिए? क्या आप अपने उत्तर का बेहतर समर्थन कर सकते हैं?
22

हां दोनों को बढ़ाना होगा। पिछली रात जब मैंने उन्हें वेतन वृद्धि से पहले जमा करने की कोशिश की, तो दोनों चाबियों के लिए शिकायत की।
xoail

अतिरिक्त सूचना के लिए धन्यवाद। बिल्ड अपलोड करते समय अपना अनुभव जोड़ने के लिए आपको अपना उत्तर संपादित करना चाहिए।
pkamb

6
"यह उन्हें समान रखने के लिए एक अच्छा अभ्यास है" - यह जरूरी सच नहीं है। यदि आपके पास आपके ऐप पर काम करने वाले परीक्षक हैं, तो आप अपने बिल्ड नंबर को बढ़ाना पसंद कर सकते हैं क्योंकि परिवर्तन लागू होते हैं, लेकिन अपने संस्करण संख्या को समान रखें। निरंतर एकीकरण का उपयोग करते हुए, आप उदाहरण के लिए, परीक्षकों को तैनात करने से पहले आपके लिए अपना बिल्ड नंबर अपडेट कर सकते हैं।
एंडी

@ और तुम सही हो, समझ में आता है। उपयोग मामले को इंगित करने के लिए धन्यवाद। मैं केवल एक ही डेवलपर / परीक्षक पर्यावरण के संदर्भ में सोच रहा था।
xoail

5

ऐप स्टोर में एक नया संस्करण जारी करते समय दोनों CFBundleVersionऔर CFBundleShortVersionString जरूरी वृद्धि की जानी चाहिए

इसके अतिरिक्त, स्ट्रिंग्स में से एक को आईट्यून्स कनेक्ट में निर्दिष्ट संस्करण से मेल खाना चाहिए।

Xcode ऑर्गनाइज़र Validator error: संस्करण संख्या बढ़ाना चाहिए।

इस प्रश्न में Xcode ऑर्गनाइज़र के Validator का उपरोक्त स्क्रीनशॉट शामिल है जब एप्लिकेशन को मान्य करने से इंकार कर दिया गया है CFBundleVersionऔर CFBundleShortVersionStringनहीं बढ़ाया गया है।

  • यह बंडल अमान्य है। CFBundleVersionInfo.plist फ़ाइल में कुंजी [1.0] का मान पहले अपलोड किए गए संस्करण [1.134] की तुलना में एक उच्च संस्करण होना चाहिए।

  • यह बंडल अमान्य है। CFBundleShortVersionStringInfo.plist फ़ाइल में कुंजी [1.0] का मान पहले अपलोड किए गए संस्करण [1.134] की तुलना में एक उच्च संस्करण होना चाहिए।

सत्यापनकर्ता एक त्रुटि भी साबित करता है कि स्ट्रिंग में से एक को आईट्यून्स कनेक्ट पर बनाए गए एप्लिकेशन के संस्करण से मेल खाना चाहिए।

  • बेमेल संस्करण। न तो CFBundleVersion ['1.0'] और न ही CFBundleShortVersionString ['1.0'] Info.plist में iTunes कनेक्ट ['1.4'] में सेट किए गए ऐप के संस्करण से मेल खाता है।

2

वर्तमान Apple तकनीकी नोट TN2420, वर्जन नंबर और बिल्ड नंबर कहते हैं (मेरी बॉडिंग):

  1. IOS ऐप्स के लिए आप विभिन्न रिलीज़ ट्रेनों में बिल्ड नंबरों का फिर से उपयोग कर सकते हैं, लेकिन आप उसी रिलीज़ ट्रेन के भीतर बिल्ड नंबरों का फिर से उपयोग नहीं कर सकते। MacOS ऐप्स के लिए, आप किसी भी रिलीज़ ट्रेन में बिल्ड नंबरों का फिर से उपयोग नहीं कर सकते हैं

दुर्भाग्य से, इसका मतलब यह है कि आप एक बिल्ड नंबर का पुन: उपयोग नहीं कर सकते हैं जो मैक कैटालिस्ट पर उसी बिल्ड को जारी करने की कोशिश करने पर iOS पर रिलीज़ ट्रेन नंबर को ट्रैक करता है।

मेरे मामले में, उदाहरण के लिए, कुछ पुराने मुद्दों के कारण, मैंने मैक कैटालिस्ट ऐप के रूप में 1.0.2 (4) जारी किया जो iOS पर 1.0.2 (1) के अनुरूप था। अब जब दोनों पर 1.0.3 (1) जारी करने की कोशिश की जा रही है, तो ऐप बिल्ड नंबर के कारण मैकओएस पर सत्यापन को विफल कर देता है, जबकि यह आईओएस पर सत्यापन से गुजरता है।

अब मुझे लगता है कि मैं iOS और MacOS दोनों पर एक ही ऐप को नियमित रूप से जारी कर रहा हूं, मैं बिल्ड संख्या को अपनाऊंगा जो 20200111 की तारीख के अनुरूप हो और एक दशमलव बिंदु के साथ वृद्धि हो अगर मुझे दिए गए रिलीज़ के भीतर बिल्ड नंबर बदलने की आवश्यकता है।


1

आपको दोनों को बढ़ाना होगा ।

एक नया संस्करण अपलोड करते समय, आपको iTunes कनेक्ट पर एक नया संस्करण बनाने की आवश्यकता होगी, जो स्वचालित रूप से पिछले रिलीज की तुलना में अधिक होगा। आईट्यून्स कनेक्ट पर यह संस्करण एक ही संस्करण संख्या के साथ एक द्विआधारी की उम्मीद कर रहा होगा, इस प्रकार CFBundleShortVersionStringवेतन वृद्धि की आवश्यकता है।

यदि आप संस्करण को अपडेट करते हैं, लेकिन वृद्धि करना भूल जाते हैं CFBundleVersion, तो आप अपलोड के दौरान एक त्रुटि का सामना करेंगे। Pkamb का उत्तर और स्क्रीनशॉट देखें।

पर CFBundleShortVersionStringऔर जानकारी के लिए CFBundleVersionकृपया देखें: https://stackoverflow.com/a/31921249/936957


1

मैं पुष्टि कर सकता हूँ, बस इसे दोनों तरीकों से आज़माया है, कि संस्करण का एक क्रम और जैसे संख्याएँ बनाएँ ...

1.0.0 (1)
1.0.1 (1)
1.0.2 (1)

... iOS ऐप्स के लिए स्वीकार किया जाएगा, लेकिन Mac (उत्प्रेरक) ऐप्स के लिए यह त्रुटि देता है:

ERROR ITMS-90061: "यह बंडल अमान्य है। Info.plist फ़ाइल में कुंजी CFBundleVersion [1] का मान पहले अपलोड किए गए संस्करण [2] की तुलना में एक उच्च संस्करण होना चाहिए।"

मैक संस्करण और बिल्ड नंबर की तरह जाने की आवश्यकता होगी ...

1.0.0 (1)
1.0.1 (2)
1.0.2 (3)

IOS के लिए, मैं वर्जन नंबर प्लस फोर्थ डिजिट के रूप में बिल्ड नंबर दर्ज करता था, जैसे ...

1.0.0 (1.0.0.1)
1.0.1 (1.0.1.1)
1.0.2 (1.0.2.1)

... लेकिन वह मैक ऐप्स के लिए अनुमति नहीं है, या तो। जब मैंने अपना पहला मैक (उत्प्रेरक) ऐप सबमिट करने की कोशिश की, तो Apple केवल तीन या उससे कम अंकों के साथ एक बिल्ड नंबर स्वीकार करेगा:

ERROR ITMS-9000: "यह बंडल अमान्य है। कुंजी CFBundleVersion [1.0.0.1] के लिए Info.plist फ़ाइल का मान अधिकतम तीन गैर-नकारात्मक पूर्णांकों की एक अलग सूची में होना चाहिए।"

इसलिए मैं एक एकल संख्या में बदल गया जो हर बिल्ड के लिए वेतन वृद्धि करता है और संस्करण संख्याओं में वृद्धि जारी रखता है।


क्या आपके पास कोई त्रुटि संदेश है जो उसने आपको दिया है? कृपया उन्हें बोली अगर ऐसा है!
pkamb

0

मैं एक नया मैक ऐप स्टोर ऐप जारी करने की तैयारी कर रहा हूं। के CalVer स्वरूपण का उपयोग करना YEAR.release (build)

मैं अपलोड की गई कई बनाता है: 2020.0 (1), 2020.0 (2), आदि मैं अंत में प्रस्तुत 2020.0 (8)App स्टोर समीक्षा के लिए। यह समीक्षा पारित हुई और राज्य लंबित डेवलपर रिलीज़ में है

मैं रिलीज से पहले कुछ चीजें ठीक करना चाहता था, इसलिए मैंने उसी रिलीज ट्रेन में एक नया निर्माण जोड़ा 2020.0 (9):।

इस परिणाम में त्रुटि है:

ऐप स्टोर कनेक्ट ऑपरेशन त्रुटि

ERROR ITMS-90062 : "यह बंडल अमान्य है। CFBundleShortVersionStringInfo.plist फ़ाइल में कुंजी [2020.0] के मूल्य में पहले से स्वीकृत संस्करण [2020.0] की तुलना में अधिक संस्करण होना चाहिए। कृपया https: // के बारे CFBundleShortVersionStringमें अधिक जानकारी प्राप्त करें। डेवलपर .apple.com/documentation/bundleresources/information_property_list/cfbundleshortversionstring "

जो मेरे 2020.0संस्करण के रूप में कष्टप्रद है वास्तव में कभी नहीं जारी किया गया था । इस प्रश्न के स्वीकृत उत्तर से मैं इस धारणा के अधीन था कि जब तक ऐप स्टोर पर उपलब्ध नहीं था तब तक आप एक ही संस्करण के साथ नए बिल्ड जारी करना जारी रख सकते हैं।

ऐसा प्रतीत होता है कि "रिलीज़ ट्रेन" (सेम वर्जन + न्यू बिल्ड) को अपडेट नहीं किया जा सकता है यदि ऐप स्टेट पेंडिंग डेवलपर रिलीज़ है । या तो अपने मौजूदा निर्माण को जारी करें और फिर संस्करण को बढ़ाएं, या इस रिलीज़ को ऐप स्टोर कनेक्ट में रद्द करें इस रिलीज़ ट्रेन के लिए आगे अपलोड करने की अनुमति दें।


-2

AFAIK, मेरे सिर के ऊपर से, आपको केवल बिल्ड नंबर बढ़ाना होगा CFBundleVersion। लघु संस्करण स्ट्रिंग को बढ़ाना आवश्यक नहीं है, हालांकि आपको संभवतः इसे बढ़ाना चाहिए, क्योंकि यह उपयोगकर्ता को बताता है कि ऐप नया है। Apple का कहना है कि नंबरिंग को पारंपरिक सॉफ्टवेयर संस्करण सम्मेलनों का पालन करना चाहिए, लेकिन यदि आप पहले से मौजूद संस्करण को फिर से अपलोड करने का प्रयास करते हैं तो iTunes कनेक्ट शिकायत कर सकता है।

लंबी कहानी छोटी, यह काम कर सकती है, लेकिन शायद नहीं।


उन आधिकारिक उत्तरों की तलाश करना जिन पर कुंजियाँ बढ़ाई जानी चाहिए। यदि CFBundleShortVersionStringवेतन वृद्धि की आवश्यकता नहीं है, तो "उसी" उपयोगकर्ता-सामना करने वाले संस्करण को कई बार ऐप स्टोर पर अपलोड किया जा सकता है?
पंब
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.