सिमेंटिक वर्शनिंग

सिमेंटिक वर्शनिंग

1) SemVer क्या है और इसकी आवश्यकता क्यों है

• मेजर - ब्रेकिंग परिवर्तन।
• MINTER एक नई API-संगत विशेषता है।
• PATCH - प्रतिवर्ती दोष सुधार।

लक्ष्य: अनुबंधों की स्थिरता पर सहमत होना और उन्नयन की लागत को कम करना।

2) संस्करण प्रारूप

• 'मेजर। माइनर। PATCH [-PRERELEESE] [+ BUILD] '

`1. 4. 7 'एक स्थिर रिलीज है।

`1. 5. 0-आरसी। 2 '- प्री-रिलीज़ (रिलीज़उम्मीदवार नंबर 2)।

`2. 0. 0 + लिनक्स। arm64 '- मेटाडेटा का निर्माण (संस्करण तुलना को प्रभावित न करें)।

1. पहले, 'मेजर' की तुलना की जाती है, फिर 'MINTER', फिर 'PATCH'।

2. प्री-रिलीज़संबंधित स्थिर संस्करण से छोटे हैं: '1। 2. 0-आरसी। 1 < 1. 2. 0`.

3. बिल्ड मेटाडेटा ('+...') क्रम को प्रभावित नहीं करता हैः '1। 2. 0+001 == 1. 2. 0`.

3) ब्रेकिंग चेंज के रूप में क्या मायने रखता

ब्रेकिंग परिवर्तन - उपभोक्ता कार्रवाई की आवश्यक

सार्वजनिक विधियों/समापन बिंदुओं के हस्ताक्षर मिटाएँ/नाम बदलें/बदलें।

इनपुट/आउटपुट प्रारूप बदलें (JSON योजना, प्रकार).

त्रुटि संविदाओं (कोड/संरचना) को संशोधित करें।

साइड-इफेक्ट्स/एसएलए बदलें (उदाहरण के लिए, सख्त सीमा या नए आवश्यक क्षेत्र)।

ब्रेकिंग नहीं (यदि सही ढंग से लागू किया जाता है): वैकल्पिक फ़ील्ड जोड़ ना, नए मानों के साथ एनम का विस्तार करना (यदि क्लाइंट उन्हें अनदेखा करता है), नए एंडपॉइंट, डिफ़ॉल्ट के साथ नए फ्लैग जो मौजूदा कॉल को प्रभावित नहीं

4) प्री-रिलीज़और चैनल रणनीतियाँ

पूर्व-रिलीज़आपको SemVer वादों को तोड़ ने के बिना परीक्षण करने की अनुमति दे

टैग: 'अल्फा', 'बीटा', 'आरसी'। उदाहरण: '2। 3. 0-बीटा। 3`.

चैनल: रात: अल्फा बीटा rc स्थिर।

नीति: पूर्व-रिलीज़को डिफ़ॉल्ट उत्पादन विधानसभाओं के लिए सकर्मक निर्भरता के रूप में नहीं गिर

5) संस्करण रेंज और बाधा सटीकता

5. 1 नोड/एनपीएम (डिफ़ॉल्ट सेमवर)

`^1. 4. 2` ≈ `>=1. 4. 2 <2. 0. 0 '(MINTER/PATCH की अनुमति देता है, मेजर को ठीक करता है)

`~1. 4. 2` ≈ `>=1. 4. 2 <1. 5. 0 '(MINTER के भीतर PATCH की अनुमति दे

`1. 4. एक्स '1 में किसी भी पैच है। 4.
सटीक पिन: '1। 4. 2`.

5. 2 अजगर (PEP 440, pip)

`~=1. 4. 2` ≈ `>=1. 4. 2,==1. 4.`.

`>=1. 4,<2. 0 '- स्पष्ट सीमाएँ।

5. 3 मावेन/ग्रेडल (जावा)

`[1. 4,2. 0) '- समावेशी/अनन्य।

खाद्य-महत्वपूर्ण कलाकृतियों के लिए सख्त किकिंग की सिफारिश की जाती है।

5. 4 गो मॉड्यूल

हमेशा 'vMAIR' टैग पूरा करें। माइनर। PATCH ';' v2 + 'के लिए मॉड्यूल प्रत्यय '/v2' की आवश्यकता होती है।

सिफारिश: अनुप्रयोगों के लिए - सटीक पिन (प्रजनन योग्य बिल्ड)। पुस्तकालयों के लिए - कैरेट रेंज (बिना टूटे अपडेट की सुविधा)।

6) CHANGELOG и पारंपरिक कमिट्स

संरचित परिवर्तन लॉग पारदर्शिता में सुधार करता है।

feat(payments): add PIX refund endpoint fix(api): correct 400 → 422 on invalid payload perf(cache): reduce p99 by 20%
refactor(core): extract rule engine docs: update API usage examples chore(deps): bump lodash to 4. 17. 21 feat!: remove legacy webhook v1 (BREAKING CHANGE:...)

Типы: 'करतब', 'फिक्स', 'पर्फ', 'डॉक्स', 'रिफैक्टर', 'कोर' и т। д.

एक विस्मयादिबोधक बिंदु या 'ब्रेकिंग चेंज' ब्लॉक एक मेजर घोषित करता है।

CHANGELOG कमिट के इतिहास से उत्पन्न होता है (बॉट द्वारा रिलीज ़-नोट्स)।

7) एपीआई के लिए वर्शनिंग पॉलिसी

सार्वजनिक एपीआई: सख्त सेमवर; → मेजर को तोड़ ना।

HTTP/REST: URL/header द्वारा वर्शनिंग: '/v1/... ', '/v2/...' या 'स्वीकार करें: अनुप्रयोग/vnd. org। सेवा। v2 + json '।

JSON स्कीमा: मामूली एक्सटेंशन - नए वैकल्पिक क्षेत्र; प्रमुख - हटाना/परिवर्तन अनिवार्

gRPC/Protobuf: नए क्षेत्रों को नए नंबरों के साथ जोड़ें; पदावनत संख्या मिटाने के लिए फ़ील्ड संख्या का पुनः उपयोग न करें, मौजूदा नहीं तोड़ रहा है.

8) डेटा और प्रवास योजनाएं

डेटाबेस माइग्रेशन को ऐप @ 1 संस्करणों के साथ सिंक्रनाइज़किया गया है। 8. 0 'schema @ 1 की आवश्यकता है। 8. एक्स '।

स्कीमा परिवर्तनों को तोड़ ने के लिए - चरण: विस्तार (जोड़ें), माइग्रेट करें, अनुबंध (हटाएं)। पुराने अनुबंध को मिटाने पर ही मेजर को अपग्रेड करें।

माइग्रेशन की अवधि के लिए डबल राइट/रीड का समर्थन करें।

9) मोनोरेपोस और माइक्रोसर्विसेस

मल्टी-पैकेज: प्रत्येक पैकेज का अपना 'मेजर' होता है। माइनर। PATCH '; केवल मेटा कलाकृतियों के लिए सामान्य रूट रिलीज चक्र।

• स्वतंत्र संस्करण (Lerna/Changesets) - अलगाव को बढ़ाता है।
• लॉक-स्टेप - आसान संचार, लेकिन अधिक गलत MAJORS।
• Microservices के लिए, एक अलग संस्करण के साथ अनुबंध (OpenAPI/Protobuf) को ठीक करें: 'अनुबंध @ 2। 1. 0 ', सेवा इसका अनुसरण करती है।

10) सीआई/सीडी में रिलीज का स्वचालन

• 'fix' → 'PATCH', 'करतब' → 'MINTER', '! '/' ब्रेकिंग' → 'मेजर'।

yaml
Pseudo-workflow steps:
- run: npx semantic-release
- run: git tag v$NEW_VERSION && git push --tags
- run: cosign sign ghcr. io/org/app:v$NEW_VERSION

CHANGELOG पीढ़ी, रिलीज नोट्स प्रकाशित करना, GitOps रेपो में निर्भरता को अद्यतन करना, यह जाँचना कि 'मुख्य' हमेशा अंतिम स्थिर टैग की ओर इशारा करता है।

11) अभाव नीति

घोषणा: MINTER रिलीज में पदावनत के रूप में कार्यक्षमता को चिह्नित करें, EOL शब्द दें (उदा। 90 दिन)।

अवलोकन: उपयोगकर्ता/किरायेदार संदर्भ के साथ विरासत समापन बिंदुओं का उपयोग लॉग करें।

विलोपन: निम्नलिखित मेजर में। प्रवासन पथ का दस्तावेजीकरण करें।

12) उदाहरण और टेम्पलेट

12. 1 नियमित SemVer सत्यापन अभिव्यक्ति

regex
^(0    [1-9]\d)\.(0    [1-9]\d)\.(0    [1-9]\d)(?--([0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)))? (?:\+([0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)))?$

12. तुलना के 2 उदाहरण

`1. 2. 3` < `1. 10. 0 '(माइनर तुलना)।

`2. 0. 0-आरसी। 1` < `2. 0. 0`.
`1. 2. 3 + बिल्ड। 5` == `1. 2. 3`.

12. 3 निर्भरता नीति (YAML उदाहरण)

yaml policy:
libraries:
default_range: "^MAJOR. MINOR. PATCH"
pin_security_critical: true services:
pin_exact: true allow_prerelease_in_nonprod: true api_contract:
require_same_minor: true forbid_major_mismatch: true

13) एंटी-पैटर्न

प्रोड में 'नवीनतम '/फ्लोटिंग टैग का उपयोग कर रहा है।

वास्तविक टूटने ("विपणन संस्करण") के बिना मेजर वृद्धि।

'PATCH' की आड़ में छिपे हुए ब्रेकिंग परिवर्तन।

उत्पादन अनुप्रयोगों की सकर्मक निर्भरता में पूर्व-रिलीज।

नए टैग (उत्परिवर्तनीय संस्करण) के बिना कलाकृतियों को बदलें।

असंगत कोड संस्करण और डेटाबेस स्कीमा।

14) कार्यान्वयन चेकलिस्ट (0-45 दिन)

0-10 दिन

SemVer को एक अनिवार्य मानक के रूप में स्वीकार करें, ब्रेकिंग मानदंड को मंजूरी दें।

पारंपरिक कमिट्स और 'ब्रेकिंग चेंज' फील्ड के साथ एक पीआर टेम्पलेट शामिल करें।

11-25 दिन

सिमेंटिक-रिलीज/चेंजसेट, CHANGELOG ऑटोजेनरेशन कनेक्ट करें।

VX टैग के खिलाफ कलाकृतियों के हस्ताक्षर और प्रकाशन को कॉन्फ़िगर करें। Y.Z '।

26-45 दिन

विरासत एपीआई उपयोग के लिए मूल्यह्रास नीति और टेलीमेट्री दर्ज करें।

अनुबंध संस्करणों (OpenAPI/Proto) और सेवाओं को तुल्यकालित करें।

नीति स्तर पर 'नवीनतम' और उत्परिवर्तनीय टैग (ओपीए/सीआई नियम) प्रतिबंधित करें।

15) परिपक्वता मैट्रिक्स

केवल SemVer टैग द्वारा प्रकाशित कलाकृतियों का%।

माइनर संस्करणों के बीच औसत प्रवासन समय।

छिपे हुए टूटने के कारण होने वाली घटनाओं की संख्या।

भंडार में पारंपरिक कमिट का कवरेज (> 95%)।

उत्पाद में फ्लोटिंग रेंज के बिना निर्भरता का अनुपात (> 90%)।

16) जब SemVer की आवश्यकता नहीं है

बाहरी उपभोक्ताओं के बिना आंतरिक तेज प्रोटोटाइप (दिनांकित संस्करण उपयुक्त है)।

प्रायोगिक सुविधाओं के साथ डेटा/मॉडल (कन्वर्टर स्तर पर संगतता के साथ बेहतर मॉडल/स्कीमा वर्शनिंग)।

एक स्थिर सार्वजनिक एपीआई के बिना सामग्री पैकेज।

17) निष्कर्ष

SemVer निर्माता और उपभोक्ता के बीच एक ट्रस्ट अनुबंध है। स्पष्ट रूप से परिभाषित करें कि संगतता क्या टूटती है, स्वचालित रिलीज प्रकार की मान्यता और कलाकृति प्रकाशन, एक पारदर्शी CHANGELOG बनाए रखते हैं, और अभाव नीतियों का पालन करते हैं। फिर अपडेट नियमित, अनुमानित और सुरक्षित हो जाएंगे - और बुनियादी ढांचे और एपीआई व्यवसाय को झटके के बिना विकसित होंगे।