npm, Cargo, Composer आणि pip हे सर्व एकाच semver shorthand चा अर्थ वेगवेगळ्या प्रकारे लावतात, आणि मी तपासलेल्या तेरा range expressions पैकी केवळ दोनच सर्व चारही मध्ये सारख्याच प्रकारे काम करतात.

मी प्रत्येक मॅनेजरसाठी स्वतंत्र parsers लिहिले, त्यांच्या अधिकृत specs चे पालन केले आणि त्यानंतर प्रत्येक range चा १९ version numbers च्या matrix सोबत तुलना केली. १३ × १९ च्या ग्रिडमधून (२४७ cells) एक विखुरलेले चित्र समोर आले: केवळ १७ cells मध्ये प्रत्येक टूलकडून एकसारखा "yes" किंवा "no" उत्तर मिळाले, आणि त्या १७ पैकी बहुतेक सर्व एकमताने दिलेले नकार (rejections) होते. थोडक्यात सांगायचे तर, "yes" पेक्षा "no" वर ही टूल्स अधिक वेळा सहमत होतात.

टूल्समध्ये तफावत का आहे

चारही मॅनेजर्स Semantic Versioning चे पालन करण्याचा दावा करतात, तरीही प्रत्येक मॅनेजरचे स्वतःचे shorthand नियम आहेत.

  • Caret (^) आणि dot-x – npm caret ला सपोर्ट करते; pip caret आणि dot-x या दोन्हीकडे दुर्लक्ष करते. यामुळेच npm आणि pip मध्ये ४९ cells चा मतभेद निर्माण होतो.
  • Bare versions – Cargo साध्या 1.2.3 ला caret range मानतो, ज्याचा अर्थ "1.x सोबत सुसंगत" असा होतो. npm आणि Composer त्याच स्ट्रिंगचा अर्थ 'exact match' असा लावतात आणि केवळ 1.2.3 स्वीकारतात.
  • Tilde (~) – Cargo चा tilde minor version निश्चित करतो (~1.2 हे 1.2.* शी जुळते पण 1.3.0 शी नाही). Composer चा tilde *major* version निश्चित करतो (~1.2हे1.*` शी जुळते). जेव्हा minor component बदलतो, तेव्हा या दोन्ही व्याख्यांमध्ये तफावत निर्माण होते.

Pre-release हाताळणी आणखी एक आश्चर्य निर्माण करते. ^1.2.3 सारख्या range मध्ये 2.0.0-rc.1 समाविष्ट होत नाही, जरी त्याचा numeric भाग upper bound पेक्षा कमी असला तरीही. नियम असा आहे: जोपर्यंत range मध्ये स्पष्टपणे pre-release identifier चा उल्लेख नसेल, तोपर्यंत pre-releases वगळले जातात.

टूल्समध्ये वापरण्यायोग्य एकमेव सुरक्षित syntax

या प्रयोगातून असे दिसून येते की explicit inequality ranges—उदा. >=1.2.0 <2.0.0—npm, Cargo, Composer आणि pip मध्ये सारख्याच प्रकारे काम करतात. प्रत्येक मॅनेजर या दोन मर्यादांना (boundaries) प्रत्यक्ष numeric limits मानतो, ज्यामध्ये कोणताही छुपा caret किंवा tilde semantics नसतो.

जर तुम्हाला "किमान 1.2 असलेली कोणतीही 1.x version" असे व्यक्त करायचे असेल, तर ते पूर्णपणे लिहा. यासाठी काही अतिरिक्त अक्षरे लागतील; परंतु यामुळे कोड जिथे कुठे रन होईल तिथे predictable resolution ची खात्री मिळते.

shorthand कधी फायदेशीर ठरते

सिंगल-लँग्वेज प्रोजेक्ट्ससाठी shorthand अजूनही आकर्षक आहे. केवळ npm ecosystem मध्ये, ^1.2.3 हे "भविष्यातील minor आणि patch releases सोबत सुसंगत" हे अर्थ थोडक्यात स्पष्ट करते. जर तुम्हाला माहित असेल की वापरले जाणारे टूल बदलणार नाही, तर Cargo चा caret किंवा Composer चा tilde देखील तसेच काम करते. धोका तेव्हा निर्माण होतो जेव्हा तोच manifest वेगवेगळ्या भाषांच्या सीमा ओलांडून पुन्हा वापरला जातो, किंवा जेव्हा एखादे CI job अनेक ecosystems मधून dependencies घेते.

निष्कर्ष

क्रॉस-लँग्वेज सुसंगततेसाठी semver shorthand वर अवलंबून राहणे ही एक जुगारासारखी गोष्ट आहे. version constraint चा अर्थ सर्वत्र एकच आहे याची खात्री करण्याचा एकमेव विश्वसनीय मार्ग म्हणजे explicit inequalities लिहिणे. जेव्हा तुम्हाला संक्षिप्तता (brevity) हवी असेल, तेव्हा एकाच ecosystem मध्ये राहा; आणि जेव्हा तुम्हाला सुसंगतता (consistency) हवी असेल, तेव्हा स्पष्टतेसाठी shorthand चा त्याग करा.