ஒரு பதிப்பு எண் MAJOR.MINOR.PATCH என்ற வடிவில் இருக்கும்:
மேலும், முன்னிலை வெளியீடுகள் (“pre-release”) மற்றும் கட்டமைப்பு தகவல்கள் (“build metadata”) கூட சேர்க்க முடியும்.
மென்பொருள் வளர வளர, அதில் பல பாக்கேஜ்களை சேர்க்க வேண்டி வருகிறது. அப்படிச் சேர்ந்த பாக்கேஜ்கள் ஒன்றோடொன்று சார்ந்திருந்தால், அவை சரியாக வேலை செய்யவேண்டும் என்றால் எல்லாம் சரியாக பொருந்தணும். இப்படி பொருந்தாமல் பிரச்சனை வரும் இடத்தை தான் “டிப்பெண்டென்சி ஹெல்” சொல்றாங்க.
ஒரு மென்பொருள் அமைப்பில் நிறைய சார்புகள் (dependencies) இருந்தால், அந்த மென்பொருளுக்கான புதிய பதிப்புகளை வெளியிடுவது விரைவில் ஒரு சிரமமான விஷயமாக மாறலாம். சார்புகள் மிகவும் உறுதியாய் இணைக்கப்பட்ட (tightly-coupled) குறிப்பிடப்பட்டால், அது version lock எனப்படும் பிரச்சனையை உருவாக்கும் – ஒரு பாக்கேஜ்-ஐ புதுப்பிக்க வேண்டும் என்றால், அதனைப் பயன்படுத்தும் மற்ற அனைத்து பாக்கேஜ்களையும் புதுப்பிக்க வேண்டிய நிலை உருவாகும். மற்றபுறம், சார்புகள் மிகவும் தளர்வாக (loose) குறிப்பிடப்பட்டால், அது version promiscuity எனப்படும் இன்னொரு பிரச்சினை-க்கு வழிவகுக்கும் – எதிர்காலத்தில் வரும் பதிப்புகள் எல்லாம் சரியாக வேலை செய்யும் என்ற தவறான நம்பிக்கையை ஏற்படுத்தும். இந்த இரண்டும் இணைந்து உங்கள் Project எளிதாகவும் பாதுகாப்பாகவும் முன்னேற்ற முடியாத நிலையை உருவாக்கும். இதுதான் dependency hell எனப்படும் சிக்கலான சூழ்நிலை.
இந்த பிரச்சனைக்கு ஒரு தீர்வாக, எப்போது எந்த வகையான மாற்றங்களுக்கு பதிப்பு எண்ணை (version number) எப்படி நிர்ணயிக்க வேண்டும் என்பதற்கான ஒரு எளிய விதிமுறைகள் மற்றும் தேவைகளை நாம் முன்வைக்கிறோம்.
இந்த விதிமுறைகள், திறந்த மூல மென்பொருளிலும்(open-source) மூடப்பட்ட(closed) மென்பொருளிலும் பயன்பட்டு வரும் பரவலான நடைமுறைகளை அடிப்படையாகக் கொண்டு உருவாக்கப்பட்டவையாகும். ஆனால் அவை அதற்கும் மீறி சில புதிய அம்சங்களையும் கொண்டிருக்கலாம்.
இந்த முறையை சரியாக பயன்படுத்த, முதலில் நீங்கள் ஒரு பொது API-யை (public API) அறிவிக்க வேண்டும். இது ஆவணமாக இருக்கலாம் அல்லது கோடின் மூலமாகவும் நிரூபிக்கப்படலாம். எதுவாக இருந்தாலும், அந்த API தெளிவாகவும் துல்லியமாகவும் இருக்க வேண்டும்.
ஒரு முறை உங்கள் public API-யை நீங்கள் publish பிறகு, அதில் செய்யப்படும் மாற்றங்களை version number-ல் சரியான முறையில் காட்ட வேண்டும்.
இதற்கான வடிவம்: X.Y.Z (அதாவது Major.Minor.Patch). API-யை பாதிக்காத bug fix-கள் ஏற்பட்டால் patch version-ஐ அதிகரிக்க வேண்டும். API-யில் பின்வட்டத்தை குலைக்காமல் (backward compatible) புதிய அம்சங்களை சேர்க்கும்போது minor version-ஐ அதிகரிக்க வேண்டும். API-யில் பின்வட்டத்தை உடைக்கும் (backward incompatible) மாற்றங்கள் செய்தால் major version-ஐ அதிகரிக்க வேண்டும்.
இந்த முறைக்கு நாம் “Semantic Versioning” என்று பெயர் வைத்திருக்கிறோம். இந்த முறையின் கீழ், ஒரு பதிப்பு எண் எப்படி கொடுக்கப்படுகிறது, எப்போது மாற்றப்படுகிறது என்பவை—all together—அந்த மென்பொருளின் உள்ளடக்கக் குறியீட்டில் (underlying code) என்ன மாற்றம் நடந்திருக்கிறது என்பதைப் புரியவைக்கும் வகையில் இருக்கும்.
இந்த ஆவணத்தில் உள்ள “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, மற்றும் “OPTIONAL” போன்ற முக்கிய வார்த்தைகள், RFC 2119 ஆவணத்தில் விவரிக்கப்பட்டுள்ள வகையில் பொருள்படுத்தப்பட வேண்டும்.
Semantic Versioning பயன்படுத்தும் மென்பொருள், ஒரு பொது API-யை அறிவிக்க வேண்டும். இந்த API, நேரடியாக கோடில் எழுதப்பட்டதாக இருக்கலாம் அல்லது ஆவணமாக மட்டுமே இருக்கலாம். எப்படியிருந்தாலும், அது துல்லியமாகவும் முழுமையாகவும் இருக்க வேண்டும்.
ஒரு சாதாரண பதிப்பு எண் X.Y.Z என்ற வடிவில் இருக்க வேண்டும், இதில் X, Y, Z என்பது பூஜ்யத்தைக் கடந்த முழுஎண்களாக இருக்க வேண்டும் மற்றும் முன்னணி பூஜ்யங்கள் (leading zeroes) இருக்கக் கூடாது.
X → பெரிய மாற்றம்
Y → சிறு பதிப்பு
Z → பிழை திருத்தம்
ஒவ்வொரு கூறும் எண்களில் முன்னேற்றமாக (numerically) அதிகரிக்க வேண்டும். உதாரணம்: 1.9.0 → 1.10.0 → 1.11.0
ஒரு பதிப்பிட்ட பாக்கேஜ் வெளியிடப்பட்ட பிறகு, அந்த பதிப்பின் உள்ளடக்கங்கள் மாற்றப்படக்கூடாது. ஏதேனும் மாற்றங்கள் செய்ய வேண்டுமானால், அது புதிய பதிப்பாக வெளியிடப்பட வேண்டும்.
பெரிய பதிப்பு சுழியம் (0.y.z) என்பது ஆரம்பக் கட்ட மேம்பாட்டுக்காக பயன்படுகிறது. இதில் எந்த விஷயமும் எந்த நேரத்திலும் மாற்றப்படலாம். இதன் public API நிலையானதாக (stable) கருதக்கூடாது.
பதிப்பு 1.0.0 என்பது பொது API-ஐ வரையறுக்கிறது. இந்த release-க்கு பிறகு, version எண் எப்படி அதிகரிக்கப்பட வேண்டும் என்பது இந்த API-யில் ஏற்படும் மாற்றங்களைப் பொருத்தது.
Patch version Z (x.y.Z | x > 0) அதிகரிக்க வேண்டும், பின்வட்டத்தை பாதிக்காத (backward compatible) bug fix-கள் மட்டும் சேர்க்கப்பட்டால். ஒரு bug fix என்பது, தவறான செயல்பாட்டை சரிசெய்யும் உட்புற மாற்றம்.
சிறு பதிப்பு Y (x.Y.z | x > 0) என்பது பின்புல ஒத்துழைப்பு கொண்ட புதிய செயல்பாடுகள் பொது API-இல் சேர்க்கப்படும்போது அவசியமாக அதிகரிக்கப்பட வேண்டும். பொது API-இல் உள்ள ஏதேனும் செயல்பாடு காலாவதியாக இருப்பதாகக் குறிக்கப்படும் நிலையில் கூட அதிகரிக்கப்பட வேண்டும். தனிப்பட்ட குறியீட்டுப் பகுதிகளில் முக்கியமான புதிய அம்சங்கள் அல்லது மேம்பாடுகள் அறிமுகமாகும் போது அதிகரிக்கலாம். இதில் பழுதுபார்த்தல் (patch level) மாற்றங்களும் சேர்க்கப்பட்டிருக்கலாம். சிறு பதிப்பு அதிகரிக்கும்போது, patch பதிப்பு 0 ஆக மீட்டமைக்கப்பட வேண்டும்.
பெரிய பதிப்பு X (X.y.z | X > 0) என்பது பொது API-இல் பின்னோக்கி பொருந்தாத (backward incompatible) மாற்றங்கள் அறிமுகமாகும் போது அவசியமாக அதிகரிக்கப்பட வேண்டும். இதில் சிறு மற்றும் பழுது திருத்தும் (patch) நிலை மாற்றங்களும் அடங்கியிருக்கலாம். பெரிய பதிப்பு அதிகரிக்கப்படும் போது, சிறு பதிப்பும் patch பதிப்பும் 0 ஆக மீட்டமைக்கப்பட வேண்டும்.
முன் வெளியீட்டு பதிப்பு (pre-release version) என்பது, patch பதிப்பிற்குப் பின்னால் ஒரு “hyphen (-)” மற்றும் புள்ளிகளால் பிரிக்கப்பட்ட அடையாளங்களின் தொடர் சேர்ப்பதன் மூலம் குறிக்கப்படலாம். இந்த அடையாளங்கள் [0-9A-Za-z-] ஆகிய ASCII எழுத்துக்கள் மற்றும் இலக்கங்கள், மற்றும் hyphen களை மட்டுமே கொண்டிருக்க வேண்டும். அடையாளங்கள் காலியாக இருக்கக் கூடாது. இலக்க அடையாளங்களில் முன்னிலையில் பூஜ்யங்கள் (leading zeroes) இருக்கக் கூடாது. முன் வெளியீட்டு பதிப்புகள், தொடர்புடைய சாதாரண (normal) பதிப்புகளைக் காட்டிலும் குறைந்த முன்னுரிமை (precedence) பெறும். ஒரு முன் வெளியீட்டு பதிப்பு என்பது அந்த பதிப்பு நிலைத்தன்மையற்றது (unstable) என்றும், அதன் தொடர்புடைய சாதாரண பதிப்பு வழங்கும் ஒத்துழைப்பு (compatibility) உத்தரவாதங்களை நிரூபிக்கவில்லை என்றும் குறிக்கிறது.
உதாரணங்கள்: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92, 1.0.0-x-y-z–.
Build metadata (அமைப்பு மேலதிகத் தகவல்) என்பது, patch அல்லது pre-release பதிப்பிற்குப் பின்னால் ஒரு “plus” குறி (+) மற்றும் புள்ளிகளால் பிரிக்கப்பட்ட அடையாளங்களின் தொடர் சேர்த்ததன்மூலம் குறிக்கப்படலாம். இந்த அடையாளங்கள் [0-9A-Za-z-] ஆகிய ASCII எழுத்துக்கள் மற்றும் இலக்கங்கள் மற்றும் hyphen களை மட்டுமே கொண்டிருக்க வேண்டும். அடையாளங்கள் காலியாக இருக்கக் கூடாது. Build metadata ஒரு பதிப்பின் முன்னுரிமையை (precedence) நிர்ணயிக்கும்போது கவனிக்கப்படக்கூடாது. எனவே, build metadata மட்டுமே வேறுபட்டிருக்கும் இரண்டு பதிப்புகள், ஒரே முன்னுரிமையைக் கொண்டதாக கருதப்படும்.
உதாரணங்கள்: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3—-117B344092BD.
முன்னுரிமை (Precedence) என்பது, பதிப்புகளை (versions) ஒவ்வொன்றுடன் ஒப்பிட்டு வரிசைப்படுத்தும்போது எப்படி ஒழுங்குபடுத்தப்படும் என்பதை குறிக்கிறது.
முன்னுரிமை கணிக்கும்போது, அந்த பதிப்பை major, minor, patch மற்றும் pre-release identifiers ஆக பிரித்து கணிக்க வேண்டும்(Build metadata இதில் பங்கெடுக்காது).
ஒவ்வொரு கூறும் இடம் வீழ்ச்சி வரிசையில் (left to right) ஒப்பிடப்பட்டு, முதல் வேறுபாடு ஏற்பட்ட இடத்தில் தான் முன்னுரிமை தீர்மானிக்கப்படும். Major, Minor மற்றும் Patch version-கள் எப்போதும் எண்ணாக ஒப்பிடப்படும். உதாரணம்: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1
Major, Minor மற்றும் Patch version-கள் சமமாக இருந்தால், pre-release version-க்கு, normal version-ஐவிட குறைந்த முன்னுரிமை இருக்கும். உதாரணம்: 1.0.0-alpha < 1.0.0
ஒரே Major, Minor மற்றும் Patch version-களுடன் இருக்கும் இரண்டு pre-release பதிப்புகளுக்குள் முன்னுரிமை தீர்மானிக்க, dot-இல் பிரிக்கப்பட்ட identifiers-ஐ இடம் வீழ்ச்சி வரிசையில் ஒப்பிட வேண்டும். வேறுபாடு தெரிந்தவுடன், அதன்படி தீர்மானிக்க வேண்டும்:
உதாரணம்: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0
<valid semver> ::= <version core>
| <version core> "-" <pre-release>
| <version core> "+" <build>
| <version core> "-" <pre-release> "+" <build>
<version core> ::= <major> "." <minor> "." <patch>
<major> ::= <numeric identifier>
<minor> ::= <numeric identifier>
<patch> ::= <numeric identifier>
<pre-release> ::= <dot-separated pre-release identifiers>
<dot-separated pre-release identifiers> ::= <pre-release identifier>
| <pre-release identifier> "." <dot-separated pre-release identifiers>
<build> ::= <dot-separated build identifiers>
<dot-separated build identifiers> ::= <build identifier>
| <build identifier> "." <dot-separated build identifiers>
<pre-release identifier> ::= <alphanumeric identifier>
| <numeric identifier>
<build identifier> ::= <alphanumeric identifier>
| <digits>
<alphanumeric identifier> ::= <non-digit>
| <non-digit> <identifier characters>
| <identifier characters> <non-digit>
| <identifier characters> <non-digit> <identifier characters>
<numeric identifier> ::= "0"
| <positive digit>
| <positive digit> <digits>
<identifier characters> ::= <identifier character>
| <identifier character> <identifier characters>
<identifier character> ::= <digit>
| <non-digit>
<non-digit> ::= <letter>
| "-"
<digits> ::= <digit>
| <digit> <digits>
<digit> ::= "0"
| <positive digit>
<positive digit> ::= "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
<letter> ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J"
| "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T"
| "U" | "V" | "W" | "X" | "Y" | "Z" | "a" | "b" | "c" | "d"
| "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n"
| "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x"
| "y" | "z"
இது ஒரு புதிய அல்லது புரட்சிகரமான யோசனை அல்ல. உண்மையில், நீங்கள் ஏற்கனவே இதற்கே நெருக்கமான முறையை பின்பற்றிக் கொண்டு இருக்கலாம். ஆனால், “நெருக்கமாக பின்பற்றுவது போதுமானதல்ல.” ஒரு முறையான விதிமுறைகளை பின்பற்றாமலே version numbers பயன்படுத்தப்படுகின்றன என்றால், அவை dependency-ஐ நிர்வகிக்க ஏதுவாக இருக்காது. மேலே கூறிய யோசனைகளுக்கு ஒரு பெயரும், தெளிவான வரையறையும் கொடுத்தால், உங்கள் மென்பொருளைப் பயன்படுத்தும் நபர்களிடம் நீங்கள் உங்கள் நோக்கத்தை எளிதாக தெரிவிக்க முடியும். இந்த நோக்கம் தெளிவாகத் தெரிந்தவுடன், தகுந்த அளவிலான (அதிகமாகவும் அல்ல, குறைவாகவும் அல்ல) வளைந்த வகை சார்பு நிபந்தனைகள் (flexible dependency specifications) அமைக்க முடியும்.
ஒரு எளிய எடுத்துக்காட்டு:
“Semantic Versioning” எப்படி dependency hell-ஐ முற்றிலும் தவிர்க்க முடியும் என்பதைக் காட்டுகிறது.
உதாரணம்: Firetruck. இது Ladder என்ற மற்றொரு பாக்கேஜை சார்ந்திருக்கும். Ladder என்பது Semantic Versioning-ஐ பின்பற்றும் ஒரு library. Firetruck உருவாக்கப்படும் நேரத்தில், Ladder பதிப்பு 3.1.0 ஆக உள்ளது. Firetruck, Ladder-ல் 3.1.0-ல் அறிமுகமான சில அம்சங்களை மட்டுமே பயன்படுத்துகிறது.
அதனால், Ladder dependency-ஐ, “3.1.0 அல்லது அதற்கும் மேலாக இருக்க வேண்டும், ஆனால் 4.0.0-க்கு கீழே இருக்க வேண்டும்” எனக் குறிப்பிடலாம்.
இந்த நிலையில், 3.1.1, 3.2.0 போன்ற Ladder updates வந்தால் கூட, அவை Firetruck உடன் வேலை செய்யும் என்பதை நம்பிக்கையுடன் package manager-க்கு சேர்க்கலாம்.
ஒரு பொறுப்புள்ள developer ஆக, நீங்கள் எப்போதும் புதிய version-கள் சரியாக இயங்கும் என சோதிக்கவேண்டியது கட்டாயமானது.
ஆனால், நீங்கள் செய்யக்கூடிய ஒன்று என்னவென்றால்: Semantic Versioning-ஐ பின்பற்றுவதன் மூலம், தேவையில்லாமல் மற்ற சார்ந்த பாக்கேஜ்களை புதுப்பிக்க வேண்டிய நிலையைத் தவிர்த்து, நேரம் சேமிக்க முடியும்.
இவை எல்லாம் உங்களுக்கு தேவைபட்டால், Semantic Versioning-ஐ பயன்படுத்த ஆரம்பிக்க செய்ய வேண்டியது ஒன்றே — நீங்கள் இதைப் பின்பற்றுகிறீர்கள் என்று அறிவிக்க வேண்டும் மற்றும் விதிமுறைகளை பின்பற்ற வேண்டும்.
உங்கள் README-யில் இந்த இணையதளத்துக்கு link கொடுத்து, மற்றவர்களும் இந்த விதிமுறைகளைப் பின்பற்றி அதன் பயன்களை பெற உதவுங்கள்.
எளிய முறையாக சொல்வதானால், உங்கள் ஆரம்ப version-ஐ 0.1.0 எனத் தொடங்குங்கள். அதற்குப் பிறகு, ஒவ்வொரு release-க்கும் minor version-ஐ (y) அதிகரிக்கவும்.
உங்கள் மென்பொருள் தயாரிப்பு நிலை (production)யில் பயன்படுத்தப்படுகிறதென்றால், அது ஏற்கனவே 1.0.0 ஆக இருக்க வேண்டியதாகும். பயனர்கள் நம்பிக்கையுடன் பயன்படுத்தும் நிலைத்தன்மையுள்ள API இருப்பின், அது 1.0.0 ஆக இருக்க வேண்டும். பழைய பதிப்புகளுடன் பொருந்தும் வகையில் மாற்றங்களை கவனமாக செய்ய வேண்டுமென நீங்கள் அதிகமாக சிந்திக்கிறீர்கள் என்றால், உங்கள் பதிப்பு ஏற்கனவே 1.0.0 ஆக இருக்க வேண்டும்.
இல்லை. Major version 0 என்பது முற்றிலும் விரைவான வளர்ச்சிக்காகவே உள்ளது. நீங்கள் API-யை தினமும் மாற்றிக் கொண்டே இருக்கிறீர்கள் என்றால், நீங்கள் இன்னும் 0.y.z பதிப்பிலேயே இருக்க வேண்டியது அல்லது அடுத்த major version-ஐ உருவாக்கும் தனி development கிளையில் (branch) வேலை செய்ய வேண்டியது தான்.
இது பொறுப்புள்ள வளர்ச்சி (responsible development) மற்றும் முன்னோக்கி சிந்திக்கும் திட்டமிடல் (foresight) தொடர்பான கேள்வி. பல பாக்கேஜ்கள் சார்ந்திருக்கும் மென்பொருளில், ஒப்பாத மாற்றங்களை எளிதில் சேர்க்கக்கூடாது. அந்த மாற்றங்களை update செய்வதற்கான செலவு பெரிதாக இருக்கலாம்.
ஒப்பாத மாற்றங்கள் இருந்தால் major version-ஐ அதிகரிக்க வேண்டிய கட்டாயம் இருக்கிறதே என்பதால்தான், நீங்கள் மாற்றங்களின் தாக்கத்தை சிந்தித்து, அதனால் ஏற்படும் செலவு/பலன் (cost/benefit) சமநிலையை மதிப்பீடு செய்வீர்கள்.
உங்கள் மென்பொருளை மற்றவர்கள் பயன்படுத்துவதற்காக உருவாக்குகிறீர்களானால், அதை சரியாக ஆவணமாக்குவது ஒரு தொழில்முறை developer ஆகும் உங்களின் பொறுப்பு.
மென்பொருள் திட்டத்தின் சிக்கல்களை நிர்வகிப்பது மிகவும் முக்கியமான ஒரு பணி. யாருக்கும் உங்கள் மென்பொருளை எப்படி பயன்படுத்துவது தெரியவில்லை என்ற நிலை இருந்தால், அல்லது எந்த method-களை பாதுகாப்பாக அழைக்கலாம் என்றே தெரியவில்லை என்றால், அந்த திட்டத்தை சரியாகவும் விரைவாகவும் நடத்த முடியாது.
நீண்ட காலத்தில் பார்ப்பதற்கேற்ப, Semantic Versioning மற்றும் ஒரு தெளிவான public API-யை கட்டாயமாக வைத்திருப்பது, முழு குழுவுக்கும் மென்மையாக வேலை செய்ய உதவும்.
நீங்கள் Semantic Versioning விதிகளை மீறி விட்டீர்கள் என்பதை உணர்ந்தவுடன், அந்த பிரச்சனையை சரிசெய்து, புதிய minor version ஒன்றை வெளியிடுங்கள் — அது அந்த பிழையை சரிசெய்ய வேண்டும் மற்றும் backward compatibility-ஐ மீண்டும் கொண்டுவர வேண்டும்.
இந்த சூழ்நிலையில் கூட, ஏற்கனவே வெளியிடப்பட்ட பதிப்பை மாற்றுவது ஏற்கக்கூடியது அல்ல.
தேவையானவரை, அந்த பிழையான version பற்றி ஆவணமாக (document) எழுதுங்கள் மற்றும் உங்கள் பயனாளர்களுக்கு அந்த version-இல் உள்ள பிரச்சனை குறித்து தெரிவியுங்கள், அவர்கள் அதைத் தவிர்க்க முடியும்.
இந்த மாதிரியான மாற்றம் compatible எனவே கருதப்படும், ஏனெனில் இது public API-யை பாதிக்கவில்லை.
உங்கள் பாக்கேஜ் பயன்படுத்தும் சார்புகளை, மற்ற மென்பொருள்களும் நேரடியாக பயன்படுத்துகிறதெனில், அவற்றுக்கு தங்களுடைய சொந்த dependency விதிமுறைகள் இருக்கும், அந்த developer-களே conflict-ஐ கவனிப்பார்கள்.
இந்த மாற்றம் patch level-ஆ அல்லது minor level-ஆ என்பதை தீர்மானிக்க, நீங்கள் அந்த dependency update-ஐ ஒரு பிழையை (bug) சரி செய்யவே செய்தீர்களா, அல்லது புதிய செயல்பாடுகளை (functionality) அறிமுகப்படுத்தவே செய்தீர்களா என்பதைக் கருத்தில் கொள்ள வேண்டும்.
புதிய அம்சங்களை சேர்க்கும் நிலை என்றால், அதற்காக புதிய code-களும் சேர்க்கப்படுவதால், minor version-ஐ அதிகரிப்பது தான் சரியானது.
உங்களுடைய சரியான மதிப்பீட்டைப் (best judgment) பயன்படுத்துங்கள். உங்கள் மென்பொருளை பயன்படுத்தும் பயனர்கள் அதிகமானவர்கள், அந்த மாற்றத்தை மீண்டும் public API-யில் இருந்தபடி மாற்றினால் அவர்களுக்கு பெரிய தாக்கம் ஏற்படப் போகிறதென்றால் — அந்த நிலைமையில், அது உண்மையில் patch-ஆகக் கருதப்பட்டாலும் கூட, ஒரு major version release செய்வது சிறந்ததாக இருக்கலாம்.
நினைவில் வைத்துக்கொள்ளுங்கள்: Semantic Versioning-ன் முக்கிய நோக்கம், version number-ல் ஏற்படும் மாற்றங்கள் மூலம் பயனாளர்களுக்குப் பொருள் சொல்ல வேண்டும் என்பதுதான்.
அந்த மாற்றங்கள் பயனர்களுக்கு முக்கியமானவை என்றால், அதனை version number-ல் வெளிப்படையாக காட்டுங்கள்.
முன்னிலையிலான (deprecated) செயல்பாடுகளை அறிவிப்பது என்பது மென்பொருள் வளர்ச்சியில் சாதாரணமான ஒன்றாகும் — முன்னேற்றம் காண இது சில நேரங்களில் தேவையானதும் கூட.
நீங்கள் உங்கள் public API-யில் உள்ள ஒரு பகுதியை deprecate செய்யும் போது, நீங்கள் இரண்டு விஷயங்களை செய்ய வேண்டும்: (1) உங்கள் ஆவணத்தில் (documentation) அந்த மாற்றத்தைப் பற்றிக் குறிப்பிடுங்கள், (2) பயனாளர்களுக்கு அது தெரியவில்லையென்றால் அவர்கள் பழைய முறையையே பயன்படுத்திக் கொண்டிருப்பார்கள். அந்த deprecation உடன் ஒரு புதிய minor version release ஒன்றை வெளியிடுங்கள். அந்த செயல்பாட்டை முழுமையாக நீக்கும் முன் (அதாவது ஒரு major version release-இல்), அதை deprecate செய்தது இடம்பெறும் குறைந்தது ஒரு minor release இருந்திருக்க வேண்டும். இதனால், பயனர்கள் புதிய API-க்கு மென்மையாக மாற transition செய்யலாம்.
இல்லை, SemVer-ல் நேரடி வரம்பு இல்லை. ஆனால், நல்ல மதிப்பீட்டுடன் (good judgment) நடந்து கொள்ள வேண்டும். உதாரணமாக, ஒரு 255 எழுத்துகளைக் கொண்ட version string என்பது தேவைக்கு மீறியது எனலாம்.
மேலும், சில systems தங்களுடைய சொந்தமாக version string-க்கு அளவு வரம்புகளை விதித்திருக்கக்கூடும், அதையும் கவனத்தில் எடுக்க வேண்டும்.
இல்லை, “v1.2.3” என்பது Semantic Version அல்ல. ஆனால், Semantic Version-க்கு முன்னால் “v” என்பதைச் சேர்ப்பது, அது ஒரு version number என்பதை குறிப்பிட commonly பயன்படுத்தப்படும் ஒரு முறையாகும் (இங்கிலீசில்).
“version” என்பதை “v” என்று சுருக்கிப் பயன்படுத்துவது, version control systems-ல் பல இடங்களில் காணப்படுகிறது.
உதாரணமாக: git tag v1.2.3 -m “Release version 1.2.3”
இந்த உதாரணத்தில் “v1.2.3” என்பது ஒரு tag name, ஆனால் அதில் உள்ள Semantic Version என்பது “1.2.3” தான்.
ஆம், இரண்டு RegEx மாதிரிகள் உள்ளன. அதில் ஒன்று named groups-ஐ பயன்படுத்துகிறது — இது Perl, PHP, R, Python, Go போன்ற named group-ஐ ஆதரிக்கும் systems-க்கு பொருத்தமானது.
இங்கே காணலாம்: https://regex101.com/r/Ly7O1x/3/
^(?P<major>0|[1-9]\d*)\.(?P<minor>0|[1-9]\d*)\.(?P<patch>0|[1-9]\d*)(?:-(?P<prerelease>(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?P<buildmetadata>[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$
மேலும் ஒன்று numbered capture groups-ஐ பயன்படுத்தும் RegEx ஆகும் — இதில் (cg1 = major, cg2 = minor, cg3 = patch, cg4 = prerelease, cg5 = buildmetadata) இந்த RegEx, ECMAScript (JavaScript), PCRE (Perl, PHP, R), Python, மற்றும் Go ஆகியவற்றுடன் பொருந்தும் (compatible).
இங்கே காணலாம்: https://regex101.com/r/vkijKf/1/
^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$
Semantic Versioning விவரக்குறிப்பை முதன்மையாக எழுதியவர் Tom Preston-Werner, அவர் Gravatar உருவாக்கியவர் மற்றும் GitHub-இன் இணை நிறுவனர் ஆவார்.
நீங்கள் ஏதேனும் கருத்துகள் தெரிவிக்க விரும்பினால், தயவுசெய்து GitHub-இல் issue ஒன்றைத் திறக்கவும்.(https://github.com/semver/semver/issues).