𝗣𝗮𝗰𝗸𝗮𝗴𝗲.𝗷𝘀𝗼𝗻 बनाम 𝗴𝗼.𝗺𝗼𝗱: वर्शन फ़ील्ड कहाँ गई?

यदि आप JavaScript से Go पर जाते हैं, तो एक चीज़ आपको हैरान कर देगी।

एक package.json फ़ाइल खोलें। आपको बिल्कुल ऊपर एक version फ़ील्ड दिखाई देगी। इसे पढ़ना आसान है। आप इसे एक pull request में बदल सकते हैं। यह आपके कोड के अंदर ही होती है।

अब एक go.mod फ़ाइल खोलें।

वर्शन वहाँ नहीं है। यह कोई गलती नहीं है। यह एक चुनाव है।

Go आपके अपने मॉड्यूल के लिए version फ़ील्ड का उपयोग नहीं करता है। इसके बजाय, यह git tags का उपयोग करता है।

यह कैसे काम करता है: • आप git tag v1.2.3 चलाते हैं • आप टैग को अपनी रिपॉजिटरी में पुश करते हैं • वह टैग आपका वर्शन बन जाता है

जब कोई go get चलाता है, तो Go सही commit खोजने के लिए आपके git tags को देखता है। टैग ही सत्य का एकमात्र स्रोत (single source of truth) है।

इस डिज़ाइन की एक बड़ी ताकत है। वर्शन कभी भी गलत कोड की ओर इशारा नहीं कर सकता। npm में, पब्लिश किया गया कोड और वर्शन फ़ील्ड अलग-अलग हो सकते हैं। Go में, वे एक ही चीज़ हैं। वर्शन ही commit है।

हालाँकि, यह आपके वर्कफ़्लो को बदल देता है:

उदाहरण: v1 github.com/you/my-app का उपयोग करता है v2 github.com/you/my-app/v2 का उपयोग करता है

यह एक ही प्रोग्राम को बिना किसी टकराव के एक ही लाइब्रेरी के दो अलग-अलग मेजर वर्शन्स का उपयोग करने की अनुमति देता है।

अधिकांश अन्य भाषाएँ वर्शन को एक फ़ाइल में रखती हैं: • Node: package.json • Rust: Cargo.toml • Python: pyproject.toml • Java: pom.xml

Go इस मामले में अलग है। यह पूरी तरह से git tags पर निर्भर करता है।

यदि आप npm का अनुभव मिस करते हैं, तो आप ldflags का उपयोग करके बिल्ड टाइम पर अपने बाइनरी (binary) में वर्शन इंजेक्ट कर सकते हैं। इससे आपका ऐप वर्शन कमांड का जवाब दे सकता है।

ट्रेड-ऑफ़ (Trade-off) सरल है: एक वर्शन फ़ील्ड को पढ़ना और रिव्यू करना आसान है, लेकिन यह गलत हो सकता है। एक git टैग को देखना कठिन है, लेकिन यह हमेशा सच होता है।

Go ने सुविधा के बजाय सच्चाई को चुना।

Go डेवलपर्स के लिए: क्या यह सबसे अच्छा मॉडल है? यदि टूल्स go.mod में वर्शन को git tag के विरुद्ध सत्यापित (verify) करते, तो क्या आप वर्शन फ़ील्ड पसंद करते?

स्रोत: https://dev.to/dalirnet/packagejson-vs-gomod-where-did-the-version-field-go-3301