रिलीज़-इंजीनियरिंग नीति

पाँच नीतियाँ नियंत्रित करती हैं कि apothem कैसे रिलीज़ होता है।

1. सिमेंटिक वर्ज़निंगCopy Anchor Link

यह परियोजना सिमेंटिक वर्ज़निंग 2.0 के अंतर्गत शिप होती है। संस्करण संख्याएँ MAJOR.MINOR.PATCH[-PRERELEASE][+BUILD] का रूप लेती हैं।

उम्मीदवार टैग vX.Y.Z-rc.N (रिलीज़ कैंडिडेट) या vX.Y.Z-alpha.N / vX.Y.Z-beta.N (अर्ली-एक्सेस) प्रारूप का उपयोग करते हैं।

2. रिलीज़ टैगCopy Anchor Link

प्रत्येक रिलीज़ main पर vMAJOR.MINOR.PATCH रूप का एक हस्ताक्षरित git टैग उतारती है। यह टैग .github/workflows/release.yml को ट्रिगर करता है, जो बिल्ड करता है, हस्ताक्षर करता है, SBOM और SLSA-3 प्रोवेनेंस उत्पन्न करता है, और GitHub Release पृष्ठ प्रकाशित करता है।

टैग परंपराएँ:

• प्रारूप — ठीक vMAJOR.MINOR.PATCH। कोई release- उपसर्ग नहीं, कोई -final प्रत्यय नहीं।
• एनोटेशन — प्रत्येक टैग एक एनोटेटेड टैग (git tag -a -s) होता है, जो टैग संदेश में रिलीज़-नोट्स सारांश रखता है।
• हस्ताक्षर — प्रत्येक टैग GPG-हस्ताक्षरित होता है। रिलीज़ वर्कफ़्लो अतिरिक्त रूप से प्रत्येक आर्टिफ़ैक्ट पर एक Sigstore कीलेस cosign हस्ताक्षर और एक SLSA-3 प्रोवेनेंस अभिलेख उत्पन्न करता है, दोनों GitHub Release पृष्ठ से संलग्न होते हैं।

रिलीज़ मॉडल: योगात्मकCopy Anchor Link

रिलीज़ योगात्मक होती हैं। प्रत्येक रिलीज़ main पर एक कमिट और एक टैग जोड़ती है; main को कभी फ़ोर्स-पुश नहीं किया जाता, और किसी भी प्रकाशित टैग, GitHub Release या npm संस्करण को न हटाया जाता है, न खिसकाया जाता है, न ही उसका पुनः उपयोग किया जाता है। प्रत्येक रिलीज़ अपना टैग, अपनी GitHub Release और अपना npm संस्करण बनाए रखती है, और सभी प्रकाशित रहती हैं। npm संस्करण अपरिवर्तनीय हैं: किसी प्रकाशित name@version को कभी बदला नहीं जा सकता, और जिस संख्या का प्रकाशन वापस लिया गया हो उसका फिर कभी उपयोग नहीं किया जा सकता। पिन किए गए इंस्टॉल और पुनरुत्पादनीय बिल्ड हर प्रकाशित टैग पर निर्भर करते हैं। रिलीज़-चक्र और रिलीज़-रिकवरी रनबुक दोनों इसी मॉडल का पालन करते हैं।

रिपॉज़िटरी का रिलीज़-मुखौटा नियम (योगदानकर्ता निर्देशों का Release Facade अनुभाग) इसी मॉडल को व्यक्त करता है। उसकी केवल-वर्तमान-संस्करण वाली आवश्यकता, जो freshness-facade नियम में प्रतिबिंबित है, इस बात पर लागू होती है कि सार्वजनिक सतहें क्या कहती हैं। यह आवश्यकता इस पर कोई सीमा नहीं लगाती कि कौन-सी रिलीज़ें प्रकाशित रहें।

3. डेप्रिकेशन नीतिCopy Anchor Link

वर्तमान सार्वजनिक समर्थन रेखा नवीनतम रिलीज़ किया गया माइनर है। जब परियोजना के कई सार्वजनिक माइनर हों, तब SECURITY.md का समर्थित-संस्करण मैट्रिक्स किसी भी अतिरिक्त केवल-गंभीर-सुधार समर्थन विंडो के लिए सत्य का स्रोत है।

डेप्रिकेशन ताल:

• घोषणा — कोई डेप्रिकेटेड प्रतीक या व्यवहार उस रिलीज़ के CHANGELOG.md ### Deprecated खंड में घोषित किया जाता है जिसमें डेप्रिकेशन उतरता है। रिलीज़ नोट्स डेप्रिकेशन घोषणा को प्रतिबिंबित करते हैं।
• छूट विंडो — डेप्रिकेटेड प्रतीक हटाए जाने से पहले कम से कम एक पूर्ण माइनर चक्र तक उपलब्ध रहते हैं।
• हटाना — हटाना एक MAJOR वृद्धि में उतरता है। प्रत्येक हटाया गया प्रतीक एक CHANGELOG.md ### Removed पंक्ति और कैसे-करें गाइड के अंतर्गत एक माइग्रेशन गाइड प्रविष्टि रखता है।

रनटाइम फ़्लोरCopy Anchor Link

Apothem दो रनटाइम फ़्लोर घोषित करता है: pyproject.toml में requires-python = ">=3.10" और package.json में "engines": {"node": ">=18"}।

• हर घोषित फ़्लोर का परीक्षण होता है। Python फ़्लोर CI quality मैट्रिक्स और CI Matrix वर्कफ़्लो में चलता है। npm Shim वर्कफ़्लो npm शिम को Node फ़्लोर पर और उसके बाद के हर LTS मेजर पर चलाता है: यह लुप्त-पूर्वापेक्षा त्रुटि, node bin/apothem.mjs --version, एक पृथक होम डायरेक्टरी में ड्राई-रन इंस्टॉल, और npx के माध्यम से पैक किए गए टारबॉल की जाँच करता है। जिस रनटाइम का परीक्षण नहीं होता, उसे घोषित नहीं किया जाता।
• जीवन-अंत का खुलासा किया जाता है। जब कोई रनटाइम, जो अब भी एक घोषित फ़्लोर है, अपस्ट्रीम जीवन-अंत तक पहुँचता है, तो इंस्टॉलेशन गाइड यह बताती है और उन संस्करणों के नाम देती है जिन्हें प्राथमिकता देनी चाहिए। Python 3.10 2026-10-01 को जीवन-अंत तक पहुँचा; Node.js 18 और 20 क्रमशः 2025-04-30 और 2026-04-30 को। तीनों समर्थित फ़्लोर बने रहते हैं।
• फ़्लोर बढ़ाना एक डेप्रिकेशन है। यह ऊपर दी गई ताल का पालन करता है: ### Deprecated के अंतर्गत एक घोषणा, कम से कम एक पूर्ण माइनर चक्र जिसमें पुराने फ़्लोर का परीक्षण होता रहता है, फिर जो रिलीज़ उसे बढ़ाती है वह बदलाव दर्ज करती है। requires-python, engines.node, इंस्टॉलरों के संस्करण प्रोब, और CI मैट्रिक्स उस रिलीज़ में एक साथ बदलते हैं।

4. ब्रेकिंग-बदलाव नीतिCopy Anchor Link

ब्रेकिंग बदलावों के लिए आवश्यक है:

1. एक RFC इश्यू — rfcs इश्यू लेबल के अंतर्गत खोला गया, जो ब्रेकिंग बदलाव, माइग्रेशन पथ और रोलबैक रणनीति का वर्णन करता है।
2. एक 30-दिवसीय टिप्पणी विंडो — RFC मर्ज से पहले कम से कम 30 दिनों तक खुला रहता है। जब प्रतिक्रिया इसकी माँग करे, तब अनुरक्षक विंडो को बढ़ा सकते हैं।
3. एक MAJOR वृद्धि — जो रिलीज़ ब्रेकिंग बदलाव उतारती है, वह MAJOR घटक को बढ़ाती है।
4. एक माइग्रेशन गाइड — बदलाव एक कैसे-करें गाइड प्रविष्टि के साथ शिप होता है जो ऑपरेटर को माइग्रेशन के माध्यम से मार्गदर्शन देती है।

5. रोलबैक नीतिCopy Anchor Link

यदि कोई रिलीज़ ऐसा रिग्रेशन दिखाती है जो अपनाने को अवरुद्ध करता है:

1. रिवर्ट — दोषपूर्ण कमिट main पर रिवर्ट किए जाते हैं।
2. आगे-सुधार रिलीज़ — एक अनुवर्ती रिलीज़ vMAJOR.MINOR.PATCH+1 के रूप में उतरती है, जो रिवर्ट और किसी भी क्रमिक सुधार को रखती है। पिछली खराब रिलीज़ GitHub Releases से नहीं हटाई जाती, और उसका npm संस्करण प्रकाशित रहता है (npm संस्करण अपरिवर्तनीय हैं) और npm deprecate से चिह्नित किया जाता है। CHANGELOG.md में एक ### Yanked एनोटेशन स्थिति का दस्तावेज़ीकरण करता है ताकि पुनरुत्पादनीय बिल्ड एक स्थिर संदर्भ पर टिके रहें।
3. संचार — रोलबैक के साथ एक security-advisories सूचना (जब सुरक्षा-प्रासंगिक हो) या घटना के लिए पिन किया गया एक GitHub इश्यू (जब विश्वसनीयता-प्रासंगिक हो) आता है।

यह भी देखेंCopy Anchor Link

• CHANGELOG.md — कैनोनिकल रिलीज़ बही-खाता।
• SECURITY.md — समर्थित-संस्करण मैट्रिक्स और रिपोर्टिंग चैनल।
• cicd-pipeline.md — CI जाँच श्रेणियाँ जो प्रत्येक रिलीज़ को गेट करती हैं।
• deployment-checklist.md — प्रति-रिलीज़ उत्पादन-तैयारी स्वीप।