यदि क्लासिक सिमेंटिक वर्जनिंग स्कीम "MAJOR.MINOR.PATCH" समझ में आता है, तो इस बात पर निर्भर करता है कि आप किसको तैनात करते हैं, और विशेष रूप से कब और कितनी बार आप अंतिम उपयोगकर्ता को तैनात करते हैं । यदि आप स्थिर रिलीज "4.5" के साथ काम करते हैं, तो यह योजना सबसे उपयोगी है, जहां आप 4.5.0 से शुरू करते हैं। संस्करण 4.5.1, 4.5.2, और इसी तरह केवल बग फिक्स शामिल हैं, जबकि आप आंतरिक रूप से पहले से ही संस्करण 4.6 पर काम करते हैं।
उदाहरण के लिए, यदि आप अपने अंतिम उपयोगकर्ता को "स्थिर शाखा" प्रदान करते हैं, तो इसे प्रारंभिक तैनाती के लिए 4.5.0, और जब भी आप एक पैच जारी करते हैं, तो 4.5.1, 4.5.2 का संस्करण दें। आपके आंतरिक "फुर्तीली" विकास और मध्य-स्प्रिंट परिनियोजन में, आपके पास पहले से ही एक संस्करण 4.6 हो सकता है, बस इसे "बीटा संस्करण" कहें। जब भी आप इसे मध्य-स्प्रिंट में तैनात करते हैं, तो "4.6.beta build 123" जैसे ऑटो-जेनरेट बिल्ड नंबर को जोड़ें। जब आपका स्प्रिंट समाप्त हो जाता है, तो इसे "4.6.0" असाइन करें, और अगले स्प्रिंट के लिए संस्करण संख्या को आंतरिक रूप से "4.7" पर स्विच करें। ".0" के साथ शुरू करना केवल एक सम्मेलन है, आप बीटा संस्करणों को टैग करने के लिए ".0" का भी उपयोग कर सकते हैं, और अपने अंतिम उपयोगकर्ताओं के लिए ".1" से शुरू कर सकते हैं। IMHO शब्द "बीटा" बहुत अधिक अभिव्यंजक है, सभी को बता रहा है कि स्प्रिंट "अभी तक पूरा नहीं हुआ है"।
यदि आप प्रत्येक बीटा संस्करण के साथ पूर्ण अंत-उपयोगकर्ता परिवर्तन लॉग जारी करते हैं, तो आप पर निर्भर है, लेकिन स्प्रिंट के अंत में परिवर्तन लॉग को पूरा किया जाना चाहिए, और जब भी आप अंतिम उपयोगकर्ता को बगफिक्स प्रदान करते हैं, तो आपको भी अपडेट करना चाहिए इतिहास के दस्तावेज।
आपको दो अलग-अलग शाखाओं को जारी करने की रणनीति मिलेगी, एक "स्थिर" शाखा जो सिमेंटिक संस्करण संख्याओं के साथ है, और एक "विकास शाखा" है जो बिल्ड नंबरों या कुछ समान के साथ चिह्नित है, बहुत सारे ओपन सोर्स उत्पादों जैसे इंकस्केप, फ़ायरफ़ॉक्स या 7-ज़िप में।
यदि, हालांकि, आप अलग-अलग स्थिर और विकास शाखाओं के साथ काम नहीं करते हैं, और आप उपयोगकर्ता को दैनिक रूप से एक नया संस्करण जारी करते हैं, तो आपको दैनिक रूप से एक संस्करण संख्या भी बढ़ाना चाहिए। ऐसे मामले के लिए, संस्करण संख्या "4.5.1", "4.5.2", ... संभवतः आपके व्यक्तिगत परिनियोजन को प्रतिबिंबित करेगा, और बग फिक्स और अन्य परिवर्तनों के बीच अंतर को इंगित नहीं करता है। यह ठीक हो सकता है, यह सिर्फ क्लासिक "सिमेंटिक वर्जनिंग" नहीं है। इस परिदृश्य में, आप संस्करण ४.५, ४.६, ४. could, ४. could, ४. versions को भी तैनात कर सकते हैं, इससे कोई वास्तविक अंतर नहीं पड़ता है।
अपने चैंज में प्रविष्टियों के बारे में अपने प्रश्न के बारे में: IMHO जब कुछ अंतिम उपयोगकर्ता को दिखाई देता है, तो आप परिवर्तन को तैनात करते ही चैंज में प्रवेश के लायक हो जाते हैं। उदाहरण के लिए, यदि आप फ़ीचर टॉगल का उपयोग करते हैं और कुछ अर्ध-बेक्ड फ़ीचर में बदलाव करते हैं, जो उपयोगकर्ता के लिए अभी तक सक्रिय नहीं है, तो यह चैंज में शामिल नहीं है। यदि आप उपयोगकर्ता के लिए कोई दृश्य परिवर्तन नहीं करते हैं, तो केवल रीफैक्टरिंग करते हैं, जो कि चैंज नहीं है। यदि आप एक बग को ठीक करते हैं जो कुछ उपयोगकर्ताओं को प्रभावित कर सकता है, तो निश्चित रूप से चैंज में आता है - और इसका उल्लेख उसी समय किया जाना चाहिए जब आप बगफिक्स को तैनात करते हैं। और इससे कोई फर्क नहीं पड़ता कि आप दैनिक या मासिक या वार्षिक रूप से जारी करते हैं।