Auto: हॉटफिक्स - पुराने नाबालिगों और पैच के लिए समर्थन पैच

@hipsstersmoothie
क्या आपके पास इसका कोई विवरण है कि इसे कैसे लागू किया जाएगा/यह व्यवहार में कैसा दिखेगा?

साथ ही, मुझे यकीन नहीं है कि मैं समझ रहा हूं कि merge into a tag अर्थ है... क्या आप संभावित रूप से स्पष्ट कर सकते हैं? मेरी समझ यह थी कि आप केवल एक शाखा के साथ एक लक्ष्य के रूप में एक पीआर बना सकते हैं।

नहीं, मैंने वास्तव में समस्या के बारे में बहुत कुछ नहीं बताया है।

साथ ही, मुझे यकीन नहीं है कि मैं समझ रहा हूं कि टैग में विलय का क्या अर्थ है

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

हालांकि थोड़ा याद करते हुए, मुझे लगता है कि मैं यही सोच रहा था:

1. टैग 1.2.3 मौजूद है, वर्तमान संस्करण 2.0 है
2. पीआर टैग 1.2.3 में बनाया गया है, 1.2.3-0 उत्पन्न करता है (0 सेवर का निर्माण हिस्सा है)

ठीक है, सेवर के निर्माण भाग का उपयोग निश्चित रूप से समझ में आता है। मैं

यदि किसी टैग पर सीधे पीआर बनाना संभव नहीं है, तो इस प्रवाह के लिए रेपो मालिकों को अपस्ट्रीम शाखा (पीआर के लिए लक्षित शाखा) पर एक टैग से एक शाखा बनाने की आवश्यकता हो सकती है। यह थोड़ा कष्टप्रद होगा, लेकिन मुझे यकीन नहीं है कि कोई बेहतर विकल्प होगा या नहीं। इसके अतिरिक्त, इस प्रकार की रिलीज़ की संभावना आम नहीं है, इसलिए शायद यह ठीक रहेगा।

पुराने प्रमुख समर्थन ( versionBranches ) के समान दृष्टिकोण का उपयोग किया जा सकता है जहां कॉन्फ़िगरेशन में एक शाखा उपसर्ग निर्दिष्ट किया जा सकता है। ऐसा लगता है कि इस सुविधा को हॉटफ़िक्स प्रकार रिलीज़ की ओर अधिक लक्षित किया जा सकता है, इसलिए कॉन्फ़िगरेशन को पुराने प्रमुख समर्थन से अलग रखने के लिए शायद समझ में आता है। तुम क्या सोचते हो?

एक उदाहरण प्रवाह इस तरह दिख सकता है:

• उपयोगकर्ता hotfix- उपसर्ग वाली शाखाओं के लिए बिल्ड आइडेंटिफ़ायर का उपयोग करके निर्माण करने के लिए ऑटो कॉन्फ़िगरेशन में निर्दिष्ट करता है
• मौजूदा प्रतिबद्ध लॉग
  <ul> <li>(tag: v2.0.0) (master)<br /> |</li> <li>(tag: v1.2.0)<br /> |</li> <li>(tag: v1.1.0)<br /> |</li> <li>(tag: v1.0.0)<br />

पुराने प्रमुख समर्थन (संस्करण शाखाओं) के समान दृष्टिकोण का उपयोग किया जा सकता है जहां एक शाखा उपसर्ग को कॉन्फ़िगरेशन में निर्दिष्ट किया जा सकता है।

मुझे यह विचार पसंद है लेकिन व्यवहार में मुझे नहीं लगता कि इसका उपयोग करना इतना मजेदार होगा। चूंकि auto बहुत कुछ जारी करता है

यदि किसी टैग पर सीधे पीआर बनाना संभव नहीं है, तो इस प्रवाह के लिए रेपो मालिकों को अपस्ट्रीम शाखा (पीआर के लिए लक्षित शाखा) पर एक टैग से एक शाखा बनाने की आवश्यकता हो सकती है। यह थोड़ा कष्टप्रद होगा, लेकिन मुझे यकीन नहीं है कि कोई बेहतर विकल्प होगा या नहीं। इसके अतिरिक्त, इस प्रकार की रिलीज़ की संभावना आम नहीं है, इसलिए शायद यह ठीक रहेगा।

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

ऊपर आपके प्रस्तावित प्रवाह के लिए यह अच्छी तरह से काम करता प्रतीत होता है। यह दुर्भाग्यपूर्ण है कि हम पीआर को टैग में नहीं बना सकते हैं! इस वर्कफ़्लो को आसान बना देगा।

इस बारे में सोचते हुए, इस सुविधा को पूरी तरह से बाहर निकालने के लिए auto में कुछ चीजों की आवश्यकता होगी:

1. नया आदेश auto hotfix : जब चलाया जाएगा तो परियोजना को शाखा में नवीनतम टैग के आधार पर एक नए हॉटफिक्स संस्करण के साथ जारी किया जाएगा
2. auto shipit लिए नई कार्यक्षमता : पता लगाएं कि क्या हम hotfixBranch और auto hotfix चलाएं

auto hotfix कैसे काम करना चाहिए इसके लिए यह या तो जा सकता है:

1. next या canary => नया हुक जो प्लगइन को यह नियंत्रित करने की अनुमति देता है कि हॉटफिक्स कैसे जारी किया जाता है चाहे वह बिल्कुल भी समर्थित हो
2. version और publish हुक का पुन: उपयोग करें और उन्हें build सेमर जारी करने में सक्षम बनाएं

दो विकल्पों में से मुझे लगता है कि मैं 1 की ओर झुक रहा हूं क्योंकि version और pubish हुक को नए तरीके से कॉल करना एक ब्रेकिंग बदलाव माना जा सकता है। इसका दोष यह है कि कुछ हुक को afterVersion नहीं कहा जाता है, जिससे कुछ प्लगइन्स काम नहीं करते हैं। हालांकि यह वर्तमान में canary और next दोनों के लिए एक समस्या है। क्योंकि वे उस हुक को भी नहीं कहते हैं। तो कुछ ऐसा जिसके बारे में तुरंत चिंतित होने की आवश्यकता नहीं है।

क्या आप इसे जोड़ने का प्रयास करने में रुचि रखते हैं?

मुझे यह विचार पसंद है लेकिन व्यवहार में मुझे नहीं लगता कि इसका उपयोग करना इतना मजेदार होगा। चूंकि ऑटो बहुत कुछ जारी करता है, इसलिए आप शाखाओं की एक पागल संख्या के साथ समाप्त हो जाएंगे।

ओह, इसका मतलब है कि यह शाखा-उपसर्ग कॉन्फ़िगरेशन के मामले में पुराने प्रमुख समर्थन के समान था। निश्चित रूप से सहमत हैं कि स्वचालित रूप से शाखाएँ बनाने से बहुत अधिक शोर होगा, विशेष रूप से बार-बार रिलीज़ होने पर,

इस बारे में सोचते हुए, इस सुविधा को पूरी तरह से बाहर निकालने के लिए ऑटो में कुछ चीजों की आवश्यकता होगी:

1. नया आदेश ऑटो हॉटफिक्स: जब रन प्रोजेक्ट को शाखा में नवीनतम टैग के आधार पर एक नए हॉटफिक्स संस्करण के साथ रिलीज़ करेगा
2. ऑटो शिपिट के लिए नई कार्यक्षमता: पता लगाएं कि क्या हम हॉटफिक्स ब्रांच में हैं और ऑटो हॉटफिक्स चलाएं

हां। मुझे लगता है कि यह आवश्यक परिवर्तनों को काफी हद तक समाहित कर देगा।

ऑटो हॉटफिक्स को कैसे काम करना चाहिए, इसके लिए यह या तो जा सकता है:

1. अगले या कैनरी का रास्ता => नया हुक जो प्लगइन को यह नियंत्रित करने की अनुमति देता है कि हॉटफिक्स कैसे जारी किया जाता है, चाहे वह बिल्कुल भी समर्थित हो
2. संस्करण का पुन: उपयोग करें और हुक प्रकाशित करें और उन्हें बिल्ड सेवर जारी करने में सक्षम बनाएं

दो विकल्पों में से मुझे लगता है कि मैं संस्करण को कॉल करने के बाद से 1 की ओर झुक रहा हूं और एक नए तरीके से हुक प्रकाशित करना एक ब्रेकिंग बदलाव माना जा सकता है। इसका दोष यह है कि कुछ हुक को बाद में नहीं कहा जाएगा, जिससे कुछ प्लगइन्स काम नहीं करेंगे। यह वर्तमान में कैनरी और अगले दोनों के लिए एक समस्या है। क्योंकि वे उस हुक को भी नहीं कहते हैं। तो कुछ ऐसा जिसके बारे में तुरंत चिंतित होने की आवश्यकता नहीं है।

उच्च स्तर, मुझे लगता है कि 1 भी समझ में आता है। मुझे यह समझने के लिए कोड के माध्यम से पता लगाना होगा कि किस आदेश के लिए कौन से हुक बुलाए जाते हैं, लेकिन यदि next , canary , & hotfix सभी समान पैटर्न का पालन करते हैं, तो किसी भी दर्द बिंदु को बाद में हल करना आसान हो जाएगा।

क्या आप इसे जोड़ने का प्रयास करने में रुचि रखते हैं?

ज़रूर , मुझे खुशी होगी।
मैं शायद अगले सप्ताह तक इसके लिए कार्यान्वयन पर एक नज़र नहीं डाल पाऊंगा, लेकिन मुझे लगता है कि यह ठीक है क्योंकि मार्च के बाद से इस मुद्दे को अपडेट नहीं किया गया है।

बहुत बढ़िया! इस पर कोई नियोजित कार्य नहीं है, इसलिए यह आप पर है

एफडब्ल्यूआईडब्ल्यू - मैं इसे एक प्लगइन के रूप में बनाने का प्रयास करने जा रहा था, जिसे आपने एक निम्न विकल्प के रूप में माना था - version-MAJOR-MINOR शाखा बनाकर। यह हमारी वर्तमान प्रक्रिया, टीबीएच पर बहुत अधिक शोर की तरह महसूस नहीं करता है। हम पहले से ही प्रत्येक रिलीज़ लाइन के लिए शाखाएँ बनाते हैं।

versionBranches का एक बड़ा हिस्सा अभी यह प्लगइन है :

    this.hooks.beforeCommitChangelog.tapPromise(
      "Old Version Branches",
      async ({ bump }) => {
        if (bump === SEMVER.major && this.config?.versionBranches) {
          const branch = `${this.config.versionBranches}${major(
            await this.hooks.getPreviousVersion.promise()
          )}`;

          await execPromise("git", [
            "branch",
            await this.git?.getLatestTagInBranch(),
          ]);
          await execPromise("git", ["push", this.remote, branch]);
        }
      }
    );

SEMVER.minor लिए समर्थन जोड़ने के लिए यह तुच्छ लगता है, लेकिन मैं स्वीकार करूंगा कि मुझे नहीं पता कि ऑटो के अन्य हिस्सों को बदलने की आवश्यकता हो सकती है।

यह पुरानी रिलीज के लिए जो होता है उसका हिस्सा है लेकिन फिर shipit में इस चेक को भी पास करना होगा

https://github.com/intuit/auto/blob/f37945b45b7fef6ffdb00ffa0250de449e02b883/packages/core/src/auto.ts#L1442

जो तब यहां जाता है और मूल रूप से केवल ओवरराइड करता है जहां से रिलीज की गणना शुरू करना है

https://github.com/intuit/auto/blob/f37945b45b7fef6ffdb00ffa0250de449e02b883/packages/core/src/auto.ts#L1509

एक विचार जो हमें पुराने नाबालिग/पैच के साथ करना है और प्रमुख नहीं है वह संभावित संस्करण बेमेल है। नाबालिगों के साथ यह शायद किसी समस्या से कम नहीं है

*  (tag: v2.0.0) (master)
| 
*  (tag: v1.1.1)
|
|  *  (tag: v1.1.2) <- Need to add logic to find an available tag 
| /
*  (tag: v1.1.0) (hotfix-feature)
|
*  (tag: v1.0.0)

तो शायद hotfix कमांड की जरूरत नहीं है। इसके बजाय यह केवल अद्वितीय संस्करण संख्या का प्रयास कर सकता है। हालांकि इसके आसपास कुछ सत्यापन की आवश्यकता हो सकती है।

नियम :

1. किसी भी पुराने नाबालिग/पैच रिलीज शाखा पर प्रमुख रिलीज नहीं कर सकता (आवश्यक)
2. किसी भी पुराने पैच रिलीज शाखा (शायद अनावश्यक?)

@hipsstersmoothie
क्या आप जानते हैं कि अब डिफ़ॉल्ट व्यवहार क्या है यदि आपके पास पुराने टैग को बनाने के लिए सीआई सेटअप है, जहां अगला टैग उपलब्ध नहीं है?

मेरा अनुमान है, क्या कोई विफलता होगी, हालांकि मुझे यकीन नहीं है कि यह त्रुटि कहां होगी (शायद टैग पुश पर?)

अर्थात:

*  (tag: v2.0.0) (master)
| 
*  (tag: v1.1.1)
|
|  *   <- what is current behavior if I try to release this commit
| /
*  (tag: v1.1.0) 
|
*  (tag: v1.0.0)

@hipstersmoothie निर्दिष्ट नियमों को लागू करने के बाहर, मुझे try to unique version number रणनीति/कार्यान्वयन के साथ एक संभावित समस्या/भ्रम दिखाई देता है। उदाहरण के लिए @hipsstersmoothie ने उदाहरण दिया, v1.1.2 दूसरों द्वारा v1.1.1 से पैच रिलीज के रूप में देखा जाएगा, लेकिन चूंकि विकास रैखिक नहीं था, इसकी गारंटी नहीं है। संभावित रूप से, v1.1.1 से v1.1.2 पीछे की ओर असंगत परिवर्तन भी हो सकता है क्योंकि यह संभावना है कि v1.1.2 v1.1.1 से परिवर्तन न हों। यदि अगला अद्वितीय संस्करण v1.1.0 से अधिक दूरी पर है (यानी: क्या होगा यदि अगला अद्वितीय संस्करण v1.1.100 ?)

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

सामान्य तौर पर, सॉफ़्टवेयर विकास आवश्यक रूप से रैखिक नहीं होता है, इसलिए सुनिश्चित नहीं है कि एक सर्वोत्तम कार्यान्वयन है।

यदि हम सामान्यीकरण करना चाहते हैं, तो शायद हमारे पास शाखा की परवाह किए बिना उपरोक्त रणनीति निर्दिष्ट करने के लिए किसी प्रकार का कॉन्फ़िगरेशन या हुक हो सकता है (या शाखा हुक के लिए पैरामीटर हो सकती है)।
इस तरह, प्लगइन्स के माध्यम से विभिन्न कार्यान्वयनों का उपयोग किया जा सकता है।

क्या आप जानते हैं कि अब डिफ़ॉल्ट व्यवहार क्या है यदि आपके पास पुराने टैग को बनाने के लिए सीआई सेटअप है, जहां अगला टैग उपलब्ध नहीं है?

आम तौर पर टैग नहीं बनते क्योंकि संदेश में प्रतिबद्धता [skip ci] होती है

यदि अगला अद्वितीय संस्करण v1.1.0 . से अधिक दूरी पर है, तो यह और अधिक जटिल और भ्रमित करने वाला हो सकता है

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

यदि हम सामान्यीकरण करना चाहते हैं, तो शायद हमारे पास शाखा की परवाह किए बिना उपरोक्त रणनीति निर्दिष्ट करने के लिए किसी प्रकार का कॉन्फ़िगरेशन या हुक हो सकता है (या शाखा हुक के लिए पैरामीटर हो सकती है)।
इस तरह, प्लगइन्स के माध्यम से विभिन्न कार्यान्वयनों का उपयोग किया जा सकता है।

आपकी पोस्ट ने मुझे बहुत आश्वस्त किया कि एक अद्वितीय टैग ढूंढना एक भ्रमित करने वाली योजना है और हमें शायद ऐसा नहीं करना चाहिए।

हो सकता है कि अगर हम मिश्रण करते हैं तो यह काम कर सकता है। पैचिंग और बूढ़ा नाबालिग आसान होना चाहिए। यह ठीक उसी तरह काम कर सकता है जैसे कि बड़ी कंपनियों के लिए oldVersionBranches:

*  (tag: v2.0.0) (master)
| 
*  (tag: v1.2.0)
|
|  *  (tag: v1.1.5) <- Can merge patched into old minor branch, maybe error when PR has `minor`
| /
*  (tag: v1.1.4) <- branch: version-1.1
|
*  (tag: v1.0.0)

तब हमें केवल पैचिंग पैच के लिए बिल्ड मेटाडेटा भाग करने की आवश्यकता होती है।

from और useVerion विकल्पों के विलय के साथ, क्या हॉटफिक्स करने का कोई अंतर्निहित तरीका है? मुझे बस आज ही एक बनाना था और इसे मैन्युअल रूप से दर्दनाक तरीके से करने का विकल्प चुना।

संदर्भ के लिए, मेरी परियोजना 7.7 पर है। हमारी परियोजना का एक प्रमुख उपभोक्ता वर्तमान में एक संस्करण जारी कर रहा है जो 7.5 पर है, एक समस्या मिली और 7.5.1 की आवश्यकता है, इसलिए उन्हें रिलीज के बीच में सब कुछ फिर से क्यूए नहीं करना पड़ा। इष्टतम नहीं है, लेकिन कभी-कभी होता है।

अभी भी मैन्युअल हस्तक्षेप के बिना मेरी जानकारी में ऐसा करने का कोई तरीका नहीं है। मुझे लगता है कि आंतरिक रूप से यहां कोई व्यक्ति अंततः इसे जोड़ने की योजना बना रहा है। मैं सहमत हूं कि यह ऑटो में एक बेहद गायब सुविधा है

सुनने में बढ़िया! धन्यवाद 🙏

हमने (मैं और @10hendersonm) इसके लिए एक समाधान विकसित किया है लेकिन यह काफी है
शामिल। हालांकि यह केवल ऑटो और प्लगइन्स का उपयोग करता है!

हमने केवल पीआर का उपयोग करके अपने प्रोजेक्ट के 7.2.1, 8.1.1 और 8.2.2 को हॉटफिक्स किया है
(बहूत सावधानी से)।

हम इस पर विचार कर सकते हैं कि यदि लोग रुचि रखते हैं तो इसे कैसे साझा करें?

गुरु, 14 जनवरी, 2021, 7:27 अपराह्न को मैट फेल्टन नोटिफिकेशन @github.com ने लिखा:

सुनने में बढ़िया! धन्यवाद 🙏

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/intuit/auto/issues/1054#issuecomment-760583830 , या
सदस्यता समाप्त
https://github.com/notifications/unsubscribe-auth/AACI3Q6RKDONYJVH6UWUPFLSZ6KZNANCNFSM4LFJ4ULQ
.

मुझे बहुत दिलचस्पी होगी!

हैलो सभी को! मुझे इसमें योगदान देने में दिलचस्पी है। मेरा प्रस्ताव निम्नलिखित है:

1. सामान्य तौर पर, auto किसी भी version-* शाखाओं का सम्मान करने का प्रयास करेगा। उदाहरण के लिए किसी भी शाखा से version-1.1.4 में एक पैच मर्ज संस्करण 1.1.5 रिलीज उत्पन्न करेगा। यदि वह संस्करण पहले ही बनाया जा चुका है, तो या तो एनपीएम रिलीज़ या गिट टैग विफल हो जाएगा, लेकिन यह सामान्य और अपेक्षित त्रुटि मामला है
2. हम versionBranches को "major" | "minor" | "patch" स्वीकार करने के लिए अपडेट कर सकते हैं, जो आपके द्वारा निर्दिष्ट के आधार पर संभावित हॉटफिक्स शाखाएं उत्पन्न करेगा। यह आपको मैन्युअल रूप से version-* शाखा बनाने की आवश्यकता के बीच व्यापार-बंद का चयन करने की अनुमति देता है और जब आपको सुधारों की आवश्यकता नहीं होती है तो बनाए रखने के लिए बहुत सारी शाखाएं समाप्त हो जाती हैं

विचार?

लेकिन वह एक सामान्य और अपेक्षित त्रुटि मामला है\

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

हम "प्रमुख" को स्वीकार करने के लिए संस्करण शाखाओं को अपडेट कर सकते हैं | "नाबालिग" | "पैच"

वर्तमान कॉन्फ़िगरेशन या तो true या प्रमुख शाखाओं के साथ उपसर्ग करने के लिए एक स्ट्रिंग हो सकता है। मुझे लगता है कि नई कॉन्फ़िगरेशन को कुछ ऐसा दिखना होगा

{
  "versionBranches": {
      "branchPrefix": "version-",
      "types": ["major", "minor"] // defaults to just major   
   }
}

उत्तर देने के लिए अंतिम प्रश्न अभी भी हॉटफिक्स हुक या कॉल संस्करण है + वर्तमान पुराने संस्करण शाखा कार्यान्वयन के लिए कोड को देखते हुए

@lshadler हमें सबसे अच्छा तरीका खोजने के लिए थोड़ी देर के लिए इस पर जोड़ी बनाने की जरूरत है।

@bmuenzenmeyer क्या आप अपने दृष्टिकोण का अवलोकन दे सकते हैं?

जितना अधिक मैं कार्यान्वयन के बारे में सोचता हूं उतना ही मुझे लगता है कि इसके लिए v11 की आवश्यकता होगी और संस्करण में अधिक संदर्भ जोड़े जाएंगे और कमांड प्रकाशित करेंगे।

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

हमें संभवतः अगली रिलीज़ को एक ही संस्करण बनाना चाहिए, बाद में संस्करण प्रकाशित होने के बाद प्रकाशित करें प्रवाह नवीनतम करता है। यह भी v11 का हिस्सा हो सकता है। यह नवीनतम वर्कफ़्लो से मेल खाना चाहिए ताकि आप समान स्वचालन जोड़ सकें।

कैनरी वर्कफ़्लो वही रह सकता है क्योंकि कैनरी के लिए कुछ भी प्रतिबद्ध नहीं होता है और आप पहले से ही कैनरी हुक को और अधिक काम करने के लिए टैप कर सकते हैं।

सभी को नमस्कार, इस पिछले साल के पागलपन के साथ, दुर्भाग्य से यह मुद्दा मुझसे दूर हो गया है।

विभिन्न दृष्टिकोणों के संबंध में, मुझे लगता है कि इन सुविधाओं के लिए हल किए जाने वाले विभिन्न उपयोग मामलों पर विचार करने में मदद मिल सकती है। मेरी राय में, मैं 2 उपयोग के मामले देख सकता हूं:

• (1) पुरानी शाखा के लिए दीर्घकालिक समर्थन (यानी: पुराना प्रमुख संस्करण)
• (2) एक विशिष्ट संस्करण के लिए अल्पकालिक समर्थन (यानी: हॉटफिक्स)

इस बातचीत के आधार पर, मुझे लगता है कि उन उपयोग मामलों में से प्रत्येक के लिए अलग-अलग दृष्टिकोण रखना समझ में आता है।

(1) एक शाखा / रिलीज ट्रैक के दीर्घकालिक समर्थन के लिए, मेरा मानना ​​​​है कि versionBranches को हल करने में सक्षम होना चाहिए। यदि इस व्यवहार को छोटे संस्करणों के लिए विस्तारित करने की इच्छा है (जैसा कि कुछ ने ऊपर उल्लेख किया है), तो यह उस कार्यक्षमता में वृद्धि हो सकती है।

(2) शॉर्ट टर्म सपोर्ट/हॉटफिक्स के लिए, उपरोक्त थ्रेड्स के आधार पर, मुझे लगता है कि हॉटफिक्स रिलीज उत्पन्न करने के लिए उपयोगकर्ताओं के लिए हमेशा सेवर के बिल्ड पार्ट का उपयोग करने का मानक तरीका होना चाहिए। यह कोड स्वामियों को उपयोग करने के लिए सुसंगत व्यवहार देता है और कुछ जटिल कॉर्नर केस परिदृश्यों से बचा जाता है। इस मामले के लिए, मुझे लगता है कि एक नया हॉटफिक्स कमांड और हुक इस्तेमाल किया जा सकता है। यह एक अलग वृद्धि हो सकती है। सामान्य तौर पर, यह उपयोग मामला अपेक्षाकृत दुर्लभ होना चाहिए क्योंकि उपभोक्ताओं को यदि संभव हो तो नवीनतम संस्करण का उपयोग करने के लिए प्रोत्साहित किया जाना चाहिए।

संपादित करें _(अल्पकालिक उपयोग के मामले के लिए, संभावित रूप से versionBranches कॉन्फ़िगरेशन को एक पैरामीटर / टॉगल / ध्वज की अनुमति देने के लिए बढ़ाया जा सकता है जो दर्शाता है कि version- शाखाओं के लिए सेवर लेबल का सम्मान करना है या हमेशा उपयोग करना है सेवर का निर्माण भाग और उन शाखाओं के लिए किसी भी लेबल को अनदेखा करें)_

क्या इन 2 के अलावा कोई अन्य उपयोग के मामले हैं जिन पर विचार किया जाना चाहिए?

क्या अलग-अलग उपयोग के मामलों के लिए अलग-अलग तरीकों पर विचार किया जाना चाहिए?

(इसके अलावा, मैं अभी भी इनमें से कुछ परिवर्तनों में मदद कर सकता हूं, लेकिन निश्चित रूप से किसी और को इसके लिए बदलाव करने से नहीं रोकना चाहता)

इसके अलावा, शाखाओं के पैटर्न के लिए एक स्पर्शरेखा विचार:

ऑटो रिलीज के लिए एक गिट टैग (रिलीज) उत्पन्न करेगा। इसका मतलब है कि एक वैध गिट रेफरी को जीथब पर धकेल दिया जाता है। अल्पकालिक समर्थन (यानी: अल्पकालिक शाखा / हॉटफिक्स शाखा) के उपयोग के मामले के लिए, इसका मतलब है कि एक उपयोगकर्ता रिलीज / गिट टैग को धक्का देने के बाद अल्पकालिक शाखा को हटा सकता है।

• निम्नलिखित टैग के साथ एक मास्टर शाखा दी गई है
  <ul> <li>(tag: v1.3.0) (master)<br /> | </li> <li>(tag: v1.2.3)<br />

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

मैं हाल ही में बिल्ड बनाने के लिए सेवर के निर्माण भाग का उपयोग करने के लिए कोड के साथ खेल रहा था। जैसा कि मैं ऐसा कर रहा था, मैं उपयोग के मामले में आया जहां नवीनतम जीथब रिलीज जरूरी नवीनतम/उच्चतम अर्थपूर्ण संस्करण नहीं था।

उदाहरण के लिए, यहां उल्लिखित उदाहरण में: https://github.com/intuit/auto/issues/1054#issuecomment -780286683, नवीनतम जीथब रिलीज v1.2.3+1 रूप में दिखाई देगी क्योंकि यह अस्थायी रूप से उच्चतम के बाद बनाया गया था संस्करण सिमेंटिक संस्करण: v1.3.0 ।

कोड संदर्भ में कुछ स्थानों के बाद से getLatestRelease , यह विभिन्न व्यवहारों को जन्म दे सकता है यदि पाइपलाइन स्पष्ट रूप से from पैरामीटर सेट नहीं करती है। अर्थात:

• रिलीज नोट्स में क्या शामिल है
• पिछले संस्करण की गणना इस प्रकार की जाती है
• संभावित रूप से ब्रेकिंग कार्यक्षमता यदि नवीनतम जीथब रिलीज हेड कमिट से उपलब्ध नहीं है

मैंने परीक्षण नहीं किया है, लेकिन मेरा मानना ​​है कि इस प्रकार के परिदृश्य मौजूदा versionBranches व्यवहार के माध्यम से भी उपलब्ध होंगे। मेरा मानना ​​​​है कि यह उस टिप्पणी से संबंधित है जिसके बारे में प्रवाह को गिट टैग/जीथब रिलीज उत्पन्न करना चाहिए:

उत्तर देने के लिए अंतिम प्रश्न अभी भी हॉटफिक्स हुक या कॉल संस्करण है + वर्तमान पुराने संस्करण शाखा कार्यान्वयन के लिए कोड को देखते हुए

हल करने के संदर्भ में, इस मुद्दे को getLatestRelease तर्क को या तो प्रतिस्थापित करके हुक रिफैक्टरिंग से स्वतंत्र रूप से हल किया जा सकता है:

• (1) listReleases का उपयोग करके जीथब रिलीज़ प्राप्त करें और फिर उच्चतम रिलीज़ संस्करण (कोई पूर्व-रिलीज़ या बिल्ड पार्ट्स) खोजने के लिए सॉर्ट करें जो पहुंच योग्य हो
• (2) या git टैग प्राप्त करें और फिर उच्चतम रिलीज़ संस्करण (कोई पूर्व-रिलीज़ या बिल्ड पार्ट्स नहीं) खोजने के लिए सॉर्ट करें जो कि पहुंच योग्य हो

यहां अंतर यह होगा कि क्या auto जीथब रिलीज या गिट टैग को सत्य के स्रोत के रूप में देखता है, जो चर्चा से संबंधित है https://github.com/intuit/auto/discussions/1867#discussioncomment -684192।

मैं शुरू में (2) की ओर झुकूंगा, जैसा

• (ए) हम अंततः गिट रेफरी (टैग) के बाद हैं और जीथब रिलीज के अन्य तत्व नहीं हैं
• (बी) यह नेटवर्क कॉल की संख्या को कम करेगा

@हिप्स्टर्समूथी ,
अगर हमें getLatestRelease तर्क को संशोधित करने की आवश्यकता है, तो आपके विचार क्या हैं (1) जीथब रिलीज बनाम (2) गिट टैग बनाम (3) कुछ और का उपयोग कर?

हाँ मल्टी पैकेज ऑटो काम करने के लिए इसे सभी नवीनतम गिटहब रिलीज सामग्री को केवल टैग पर दोबारा करने की आवश्यकता होगी। 2 इस काम को पूरा करने के लिए साथ जाने का विकल्प है।