𝗣𝗮𝗰𝗸𝗮𝗴𝗲.𝗷𝘀𝗼𝗻 بمقابلہ 𝗚𝗼.𝗺𝗼𝗱: ورژن فیلڈ کہاں چلی گئی؟

اگر آپ JavaScript سے Go کی طرف منتقل ہوتے ہیں، تو ایک چیز آپ کو حیران کر دے گی۔

package.json فائل میں، ورژن بالکل اوپر ہوتا ہے۔ آپ اسے پڑھ سکتے ہیں۔ آپ اسے pull request میں تبدیل کر سکتے ہیں۔ آپ اسے تلاش کر سکتے ہیں۔ یہ ایک حقیقت ہے جو آپ کے کوڈ کے اندر موجود ہوتی ہے۔

اب ایک go.mod فائل کھولیں۔ ورژن وہاں موجود نہیں ہے۔

یہ کوئی غلطی نہیں ہے۔ یہ ایک انتخاب ہے۔

Go آپ کے اپنے ماڈیول کے لیے ورژن فیلڈ کا استعمال نہیں کرتا۔ اس کے بجائے، Go git tags کا استعمال کرتا ہے۔

Go میں ورژن سیٹ کرنے کے لیے، آپ یہ کرتے ہیں:

git tag ہی سچائی کا واحد ذریعہ (single source of truth) ہے۔ جب کوئی go get چلاتا ہے، تو Go صحیح commit تلاش کرنے کے لیے آپ کے ریپوزٹری ٹیگز کو دیکھتا ہے۔

اس ڈیزائن کی ایک بڑی خوبی ہے۔ ورژن کبھی بھی غلط کوڈ کی طرف اشارہ نہیں کر سکتا۔ npm میں، پبلش شدہ کوڈ اور ٹیگ شدہ سورس ایک دوسرے سے الگ ہو سکتے ہیں۔ Go میں، وہ ایک ہی چیز ہیں کیونکہ ورژن ایک commit کا پوائنٹر ہوتا ہے۔

تاہم، یہ آپ کے ورک فلو (workflow) کو کئی طریقوں سے تبدیل کر دیتا ہے:

زیادہ تر دوسرے ایکو سسٹم (ecosystems) ورژن کو ایک فائل میں رکھتے ہیں:

Go مختلف ہے۔ یہ صرف git tags پر انحصار کرتا ہے۔

اگر آپ چاہتے ہیں کہ آپ کا Go binary ایک صاف ورژن دکھائے، تو آپ build process کے دوران ldflags کا استعمال کرتے ہوئے اسے شامل (inject) کر سکتے ہیں۔ بہت سے ڈویلپرز ٹیگ اور ریلیز کے عمل کو خودکار بنانے کے لیے goreleaser جیسے ٹولز بھی استعمال کرتے ہیں۔

یہ دونوں ماڈلز مختلف ترجیحات کی نمائندگی کرتے ہیں:

Go نے ٹیگ ماڈل کا انتخاب اس لیے کیا تاکہ اس بات کو یقینی بنایا جا سکے کہ مینی فیسٹ (manifest) ہمیشہ کوڈ کے مطابق رہے۔

جو لوگ Go کوڈ پبلش کرتے ہیں: آپ کے روزمرہ کے کام میں صرف ٹیگ والا ماڈل (tag-only model) کیسا محسوس ہوتا ہے؟ کیا آپ اس میں کوئی تبدیلی لائیں گے؟

ماخذ: https://dev.to/dalirnet/packagejson-vs-gomod-where-did-the-version-field-go-3301