npm, Cargo, Composer અને pip બધા જ એક જ semver shorthand ને અલગ રીતે સમજે છે, અને મેં ટેસ્ટ કરેલા તેર રેન્જ એક્સપ્રેશન્સમાંથી માત્ર બે જ ચારેયમાં સમાન રીતે વર્તે છે.

મેં દરેક મેનેજર માટે અલગ પાર્સર્સ લખ્યા, તેમના સત્તાવાર સ્પેસિફિકેશન્સનું પાલન કર્યું, અને પછી દરેક રેન્જને ઓગણીસ વર્ઝન નંબર્સના મેટ્રિક્સ સામે ચલાવી. 13 × 19 ગ્રીડ (247 સેલ્સ) એ એક વિખરાયેલું ચિત્ર રજૂ કર્યું: માત્ર 17 સેલ્સમાં જ દરેક ટૂલમાંથી સમાન "yes" અથવા "no" જવાબ મળ્યો, અને તે 17 માંથી મોટાભાગના સર્વસંમતિથી નકારવામાં આવ્યા હતા. ટૂંકમાં, ટૂલ્સ "yes" કરતા "no" પર વધુ વાર સહમત થાય છે.

ટૂલ્સ શા માટે અલગ પડે છે

ચારેય મેનેજર્સ Semantic Versioning અનુસરવાનો દાવો કરે છે, છતાં દરેકના પોતાના shorthand નિયમો છે.

  • Caret (^) અને dot-x – npm caret ને સપોર્ટ કરે છે; pip caret અને dot-x બંનેને અવગણે છે. માત્ર આના કારણે જ npm અને pip વચ્ચે 49-સેલનો મતભેદ ઊભો થાય છે.
  • Bare versions – Cargo સાદા 1.2.3 ને caret રેન્જ તરીકે ગણે છે, જેનો અર્થ છે "1.x સાથે સુસંગત". npm અને Composer એ જ સ્ટ્રિંગને ચોક્કસ મેચ (exact match) તરીકે વાંચે છે, અને માત્ર 1.2.3 ને જ સ્વીકારે છે.
  • Tilde (~) – Cargo નું tilde minor વર્ઝનને પિન કરે છે (~1.2 એ 1.2.* સાથે મેચ થાય છે પણ 1.3.0 સાથે નહીં). Composer નું tilde *major* વર્ઝનને પિન કરે છે (~1.2એ1.*` સાથે મેચ થાય છે). કોઈપણ વર્ઝન જે minor ઘટક બદલે છે તેના પર આ બંને અર્થઘટનો અલગ પડે છે.

Pre-release હેન્ડલિંગ વધુ આશ્ચર્ય ઉમેરે છે. ^1.2.3 જેવી રેન્જમાં 2.0.0-rc.1 નો સમાવેશ થતો નથી, ભલે તેનો સંખ્યાત્મક ભાગ અપર બાઉન્ડ (upper bound) કરતા ઓછો હોય. નિયમ: જ્યાં સુધી રેન્જમાં સ્પષ્ટપણે pre-release આઈડેન્ટિફાયરનો ઉલ્લેખ ન હોય ત્યાં સુધી pre-releases ને બાકાત રાખવામાં આવે છે.

એકમાત્ર સુરક્ષિત cross-tool સિન્ટેક્સ

પ્રયોગ દર્શાવે છે કે સ્પષ્ટ અસમાનતા રેન્જ (explicit inequality ranges)—દા.ત. >=1.2.0 <2.0.0—npm, Cargo, Composer અને pip માં સમાન રીતે વર્તે છે. દરેક મેનેજર આ બે સીમાઓને સીમીત સંખ્યાત્મક મર્યાદાઓ તરીકે ગણે છે, જેમાં કોઈ છુપા caret અથવા tilde અર્થઘટન હોતું નથી.

જો તમારે "કોઈપણ 1.x વર્ઝન જે ઓછામાં ઓછું 1.2 હોય" તે દર્શાવવું હોય, તો તેને પૂરેપૂરું લખો. તેનાથી થોડા વધારાના અક્ષરો વપરાશે; પરંતુ તે કોડ જ્યાં પણ ચાલે ત્યાં અનુમાનિત રિઝોલ્યુશનની ખાતરી આપે છે.

જ્યારે shorthand હજુ પણ યોગ્ય લાગે છે

સિંગલ-લેંગ્વેજ પ્રોજેક્ટ્સ માટે shorthand આકર્ષક રહે છે. શુદ્ધ npm ઇકોસિસ્ટમમાં, ^1.2.3 ટૂંકમાં "ભવિષ્યના minor અને patch રિલીઝ સાથે સુસંગત" હોવાનો અર્થ સમજાવે છે. જ્યારે તમે જાણતા હોવ કે ઉપયોગ કરતું ટૂલ બદલાશે નહીં, ત્યારે Cargo ના caret અથવા Composer ના tilde માટે પણ આ જ વાત લાગુ પડે છે. જોખમ ત્યારે ઊભું થાય છે જ્યારે એક જ મેનિફેસ્ટનો ઉપયોગ અલગ-અલગ લેંગ્વેજ બાઉન્ડ્રીઝમાં કરવામાં આવે છે, અથવા જ્યારે CI જોબ મલ્ટિપલ ઇકોસિસ્ટમ્સમાંથી ડિપેન્ડન્સીઝ ખેંચે છે.

મુખ્ય વાત (Takeaway)

ક્રોસ-લેંગ્વેજ સુસંગતતા માટે semver shorthand પર આધાર રાખવો એ એક જુગાર છે. વર્ઝન કન્સ્ટ્રેઈન્ટ (version constraint) દરેક જગ્યાએ એક જ અર્થ ધરાવે છે તેની ખાતરી કરવાની એકમાત્ર વિશ્વસનીય રીત એ છે કે સ્પષ્ટ અસમાનતાઓ (explicit inequalities) લખવી. જ્યારે તમારે સંક્ષિપ્તતાની જરૂર હોય, ત્યારે સિંગલ ઇકોસિસ્ટમમાં રહો; જ્યારે તમારે સુસંગતતાની જરૂર હોય, ત્યારે સ્પષ્ટતા માટે shorthand નો ત્યાગ કરો.