कुछ भी के साथ, यह निर्भर करता है। क्या आपने एक अलग सीआई पैकेज भंडार का उपयोग करने पर विचार किया है जहां कोर मॉड्यूल के लिए हर प्रतिबद्धता सीआई पैकेज बनाती है?
सबसे बड़ी चुनौती आईएमओ पैकेजिंग संस्करण
है, क्योंकि NuGet अभी तक पूरी तरह से सेमवीर का समर्थन नहीं करता है (उदाहरण के लिए प्री-रिलीज संस्करण + बिल्ड नंबर)
।
संपादित करें: nuget.org अब सेमवीर 2.0 पैकेज संस्करणों का समर्थन करता है। यह spec देखें: https://github.com/NuGet/Home/wiki/SemVer2-support-for-nuget.org-%28server-side%29
सेमवीर का सही ढंग से उपयोग करें। आप आमतौर पर जारी संस्करण संख्या को पहले से नहीं जानते हैं, इसलिए आपका सीआई पैकेज संस्करण नवीनतम स्थिर रिलीज से जारी है। सीआई पैकेज जैसे प्री-रिलीज माना जाता है।
उदाहरण: 2.2.0-CI201209140650 (जो आगामी 2.2.0 रिलीज के लिए 2012-09-14 को 06:50 पर लिया गया सीआई निर्माण है) < - नोट: यह रिलीज़ संस्करण अभी भी बदल सकता है, लेकिन हमेशा होने वाला है एक अद्यतन पथ।
यदि आप सेमवीर v2.0.0 अपनाते हैं, तो आप निम्न उदाहरण भी अपना सकते हैं: 2.2.0-CI.2012.09.14.06.50।
महत्वपूर्ण नोट: nuget.org (और हद से किसी अन्य NuGet सर्वर/सेवा बाहर इस तरह के MyGet या VSTS) अनेक पैकेज संस्करणों निर्माण मेटाडाटा से केवल भिन्न का समर्थन नहीं करता!
इसने इन बाधाओं (और कुछ उचित टीमसिटी बिल्ड कॉन्फ़िगरेशन) का उपयोग करके मेरे लिए काम किया है।
- उचित
- अनुस्मारक वर्ज़निंग उचित पैकेज स्रोत (चुनने के लिए अपने सीआई pkgs पूर्व विज्ञप्ति और रिलीज से अलग रखना, हालांकि तकनीकी रूप से अपने सीआई पैकेज है: तो संक्षेप में, इन बाधाओं रहे हैं प्री-रिलीज के रूप में संस्करणित)
- एक सीआई पीकेजी से प्री-रिलीज में अपग्रेड करना एक समस्या हो सकती है यदि प्री-रिलीज टैग "सीआई" (जैसे "अल्फा") से अधिक स्ट्रिंग-सॉर्ट किया गया हो। इस मामले में: अनइंस्टॉल-पैकेज "सीआई" के बाद इंस्टाल-पैकेज "अल्फा"।
आशा है कि इससे मदद मिलती है!
स्रोत
2012-09-14 04:56:43
SourceTree स्वचालित रूप से पता लगाएगा कि submodules में असामान्य संपादन शामिल हैं और जब भी आप मूल परियोजना को प्रतिबद्ध करते हैं तो उन्हें प्रतिबद्ध करने के लिए संकेत देते हैं। –
मुझे आश्चर्य है कि आप किसके साथ खत्म हो जाते हैं?हम Nuget से गिट submodules के लिए जाने के बारे में सोचते हैं। मुझे यह पसंद नहीं है कि हमारे nuget संकुल में पीडीबी फाइलें नहीं हैं (आकार घटाने के लिए) .बगिंग जटिल है। किसी भी समाधान में सभी परियोजनाओं को रखना अच्छा लगेगा कि आप डिबगिंग करते समय कदम उठा सकते हैं। एक और संभावित समस्या एक भंडारण आकार है। हम सोनाटाइप नेक्सस का उपयोग करते हैं और पैकेज के लिए लगभग अनिश्चितकालीन प्रतिधारण नीति की आवश्यकता होती है क्योंकि कुछ पैकेज की आवश्यकता हो सकती है यदि वे 10 वर्ष की हो। इन पैकेजों के कारण क्रॉस निर्भरता nuget archives/packages बार-बार dlls होगा। डर है कि इसे बहुत सी जगह – user1325696