रिलीज़ नीति

OpenClaw चार उपयोगकर्ता-सामना करने वाले अपडेट चैनल उपलब्ध कराता है:

stable: npm पर प्रमोट किया गया नियमित रिलीज़ latest
extended-stable: npm पर पिछले पूर्ण महीने की .33+ रखरखाव लाइन extended-stable
beta: npm पर प्रीरिलीज़ टैग beta
dev: main का बदलता हुआ हेड

Extended-stable नियमित latest या main चयनकर्ताओं को बदले बिना पिछले महीने का Gateway, आधिकारिक npm plugins और Docker इमेज जारी करता है। Tideclaw अल्फ़ा बिल्ड एक अलग आंतरिक प्रीरिलीज़ ट्रैक (npm dist-tag alpha) हैं, जिनका विवरण NPM वर्कफ़्लो इनपुट और रिलीज़ टेस्ट बॉक्स में दिया गया है।

संस्करण नामकरण

मासिक Gateway extended-stable रिलीज़ संस्करण: YYYY.M.PATCH, PATCH >= 33 के साथ, git टैग vYYYY.M.PATCH
दैनिक/नियमित अंतिम रिलीज़ संस्करण: YYYY.M.PATCH, PATCH < 33 के साथ, git टैग vYYYY.M.PATCH
नियमित फ़ॉलबैक सुधार रिलीज़ संस्करण: YYYY.M.PATCH-N, git टैग vYYYY.M.PATCH-N
Beta प्रीरिलीज़ संस्करण: YYYY.M.PATCH-beta.N, git टैग vYYYY.M.PATCH-beta.N
अल्फ़ा प्रीरिलीज़ संस्करण: YYYY.M.PATCH-alpha.N, git टैग vYYYY.M.PATCH-alpha.N
महीने या पैच में कभी शून्य-पैडिंग न करें
PATCH एक क्रमिक मासिक रिलीज़-ट्रेन संख्या है, कैलेंडर दिवस नहीं। नियमित अंतिम और beta रिलीज़ वर्तमान ट्रेन को आगे बढ़ाते हैं; केवल-अल्फ़ा टैग कभी भी beta/नियमित पैच संख्या का उपयोग नहीं करते या उसे आगे नहीं बढ़ाते, इसलिए beta या नियमित ट्रेन चुनते समय अधिक पैच संख्या वाले पुराने केवल-अल्फ़ा टैग अनदेखे करें।
अल्फ़ा/रात्रिकालीन बिल्ड अगले अप्रकाशित पैच ट्रेन का उपयोग करते हैं और दोहराए गए बिल्ड के लिए केवल alpha.N बढ़ाते हैं। उस पैच का beta आ जाने पर, नए अल्फ़ा बिल्ड अगले पैच पर चले जाते हैं।
npm संस्करण अपरिवर्तनीय हैं: प्रकाशित टैग को कभी न हटाएँ, दोबारा प्रकाशित न करें या पुनः उपयोग न करें। इसके बजाय अगली प्रीरिलीज़ संख्या या अगला मासिक पैच जारी करें।
latest वर्तमान नियमित/दैनिक npm लाइन का अनुसरण करना जारी रखता है; beta वर्तमान beta इंस्टॉल लक्ष्य है
extended-stable का अर्थ समर्थित पिछले-महीने का Gateway वितरण है, जो पैच 33 से शुरू होता है; पैच 34 और उसके बाद के संस्करण उस मासिक लाइन के रखरखाव रिलीज़ हैं
नियमित अंतिम और नियमित सुधार रिलीज़ डिफ़ॉल्ट रूप से npm beta पर प्रकाशित होते हैं; रिलीज़ ऑपरेटर स्पष्ट रूप से latest को लक्षित कर सकते हैं या बाद में जाँचे-परखे beta बिल्ड को प्रमोट कर सकते हैं
Gateway extended-stable core, npm पर प्रकाशित किए जा सकने वाले प्रत्येक आधिकारिक plugin, और उसकी Docker इमेज को एक ही सटीक संस्करण पर प्रकाशित करता है; नीचे समर्पित वर्कफ़्लो देखें।
प्रत्येक नियमित अंतिम रिलीज़ npm पैकेज, macOS ऐप, हस्ताक्षरित स्टैंडअलोन Android APK और हस्ताक्षरित Windows Hub इंस्टॉलर एक साथ जारी करता है। Beta रिलीज़ सामान्यतः पहले npm/पैकेज पथ को सत्यापित और प्रकाशित करते हैं, जबकि नेटिव ऐप बिल्ड/साइन/नोटराइज़/प्रमोट नियमित अंतिम रिलीज़ के लिए आरक्षित रहता है, जब तक कि स्पष्ट रूप से अनुरोध न किया जाए।

रिलीज़ आवृत्ति

रिलीज़ पहले beta पर जाती हैं; stable केवल नवीनतम beta के सत्यापित होने के बाद आता है
अनुरक्षक सामान्यतः वर्तमान main से बनाई गई release/YYYY.M.PATCH शाखा से रिलीज़ जारी करते हैं, ताकि रिलीज़ सत्यापन और सुधार main पर नए विकास को अवरुद्ध न करें
यदि कोई beta टैग पुश या प्रकाशित हो चुका है और उसमें सुधार आवश्यक है, तो अनुरक्षक पुराने टैग को हटाने या दोबारा बनाने के बजाय अगला -beta.N टैग जारी करते हैं
विस्तृत रिलीज़ प्रक्रिया, अनुमोदन, क्रेडेंशियल और पुनर्प्राप्ति नोट केवल अनुरक्षकों के लिए हैं

मासिक Gateway extended-stable प्रकाशन

पूर्ण महीने YYYY.M के लिए, extended-stable/YYYY.M.33 बनाएँ और उस शाखा से .33+ प्रकाशित करें। टैग, शाखा, चेकआउट, पैकेज संस्करण, प्रीफ़्लाइट और सत्यापन को एक ही कमिट की पहचान करनी चाहिए। .33 से पहले, संरक्षित main में पैच 33 से नीचे के किसी बाद के महीने का अंतिम संस्करण होना चाहिए; बाद के रखरखाव पैच पात्र बने रहते हैं।

उम्मीदवार तैयार और स्थिर करें

असंपरीक्षित मेनलाइन रेंज का ऑडिट करें, निजी सुरक्षा कार्य का मिलान करें, एक सीमित बैकपोर्ट सेट अनुमोदित करें और एक समन्वित PR लैंड करें। कैनोनिकल शाखा को सीधे पुश न करें। कैनोनिकल शाखा पर, YYYY.M.P सेट करें, pnpm release:prep चलाएँ और प्रकाशित किए जा सकने वाले प्रत्येक आधिकारिक plugin में उसी संस्करण की आवश्यकता रखें। अनुमोदित लेज़र से, ### Highlights, ### Changes और ### Fixes के साथ एक पूर्ण ## YYYY.M.P अनुभाग जनरेट और कमिट करें, तथा समतुल्य बैकपोर्ट के लिए मूल मर्ज किए गए main PR उद्धृत करें। प्रीफ़्लाइट अनुपस्थित या खाली अनुभाग को अस्वीकार करता है। वर्तमान-main की पूरी Docker रिलीज़-चैनल इकाई साथ लाएँ: वर्कफ़्लो, प्रमोटर, नीति, साझा वर्गीकारक, परीक्षण और वर्कफ़्लो सत्यापन। GitHub टैग किए गए कमिट से टैग वर्कफ़्लो लोड करता है; अधूरी प्रति बिल्ड के बाद विफल हो सकती है या नियमित उपनामों को बदल सकती है। केंद्रित जाँच चलाएँ। पूरी शाखा-टिप SHA को फ़्रीज़ करें। टैग करने से पहले, उसके सटीक npm बाइट्स का प्रीफ़्लाइट करें और उस SHA के विरुद्ध पूर्ण रिलीज़ सत्यापन चलाएँ:

RELEASE_SHA="$(git rev-parse HEAD)"

gh workflow run openclaw-npm-release.yml \
  --ref extended-stable/YYYY.M.33 \
  -f tag="$RELEASE_SHA" \
  -f preflight_only=true \
  -f npm_dist_tag=extended-stable

gh workflow run full-release-validation.yml \
  --ref extended-stable/YYYY.M.33 \
  -f ref=extended-stable/YYYY.M.33 \
  -f release_profile=stable

SHA रूप केवल प्रीफ़्लाइट के लिए है। कैनोनिकल शाखा पर सत्यापन चलाएँ; प्रकाशन उसके वर्कफ़्लो रेफ़, हेड/लक्ष्य SHA, रन ID और प्रयास को बाँधता है। दोनों ID और सफल run_attempt सहेजें; release-ci/* साक्ष्य अस्वीकार करें। संपादन से पहले विफलताओं को वर्गीकृत करें:

उत्पाद: एक और अनुमोदित बैकपोर्ट PR लैंड करें।
फ़्रीज़ किए गए लक्ष्य की टूलिंग: केवल सबसे छोटा संगतता सुधार बैकपोर्ट करें जो पुराने उत्पाद को अपरिवर्तित रखते हुए जाँचता है।
प्रदाता, अनुमोदन, रनर या सेवा: उम्मीदवार को अपरिवर्तित रखें और सीमित पुनःप्रयास पथ का उपयोग करें।

शाखा में कोई भी बदलाव दोनों गेट अमान्य कर देता है। उनके पास होने के बाद, सुनिश्चित करें कि टिप अब भी RELEASE_SHA के बराबर है, फिर हस्ताक्षरित vYYYY.M.P पुश करें। बाद के बदलावों के लिए अगला पैच आवश्यक है; टैग को कभी न बदलें या हटाएँ। उसका पुश Docker Release शुरू करता है।

npm पैकेज प्रकाशित करें

npm पर प्रकाशित किए जा सकने वाले प्रत्येक आधिकारिक plugin को उसी SHA से प्रकाशित करें और सफल रन ID सहेजें:

RELEASE_SHA="$(git rev-parse HEAD)"
gh workflow run plugin-npm-release.yml \
  --ref extended-stable/YYYY.M.33 \
  -f publish_scope=all-publishable \
  -f ref="$RELEASE_SHA" \
  -f npm_dist_tag=extended-stable

वर्कफ़्लो अपरिवर्तित पैकेजों सहित सभी all-publishable पैकेजों को शामिल करता है, और प्रत्येक सटीक संस्करण और चयनकर्ता को सत्यापित करता है। पुनःरन प्रकाशित संस्करणों का पुनः उपयोग करते हैं। फिर तीनों सहेजी गई रन पहचानों के साथ तैयार core टारबॉल प्रकाशित करें:

gh workflow run openclaw-npm-release.yml \
  --ref extended-stable/YYYY.M.33 \
  -f tag=vYYYY.M.P \
  -f preflight_only=false \
  -f npm_dist_tag=extended-stable \
  -f preflight_run_id=<npm-preflight-run-id> \
  -f full_release_validation_run_id=<full-validation-run-id> \
  -f full_release_validation_run_attempt=<full-validation-run-attempt> \
  -f plugin_npm_run_id=<plugin-npm-run-id>

केवल गैर-उत्पादन पूर्वाभ्यास के लिए, प्रीफ़्लाइट और प्रकाशन में -f bypass_extended_stable_guard=true जोड़ें। यह केवल महीना गार्ड को बायपास करता है, कैनोनिकल-रेफ़, SHA/टैग/संस्करण समानता, उद्गम, अनुमोदन या रीडबैक जाँच को कभी नहीं। उत्पादन के लिए इसका कभी उपयोग न करें।

सत्यापित करें और पुनर्प्राप्त करें

फ़्रीज़ की गई शाखा के बजाय, एक अलग साफ़ वर्तमान-main चेकआउट से चलाएँ:

node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.P
npm view openclaw@YYYY.M.P version --userconfig "$(mktemp)"
npm view openclaw@extended-stable version --userconfig "$(mktemp)"

कैनोनिकल शाखा के लिए हस्ताक्षर और npm उद्गम, तथा रिलीज़ SHA से प्रकाशन, प्रीफ़्लाइट और टारबॉल-डाइजेस्ट बाइंडिंग आवश्यक करें। दोनों कमांड को YYYY.M.P लौटाना चाहिए। प्रत्येक तैयार core पैकेज और all-publishable आधिकारिक plugin को उसके सटीक संस्करण और चयनकर्ता पर सत्यापित करें। यदि केवल रूट चयनकर्ता विफल होता है, तो वर्कफ़्लो सारांश में मुद्रित जनरेट किया गया npm dist-tag add openclaw@YYYY.M.P extended-stable सुधार कमांड उपयोग करें। मौजूदा plugin या अन्य तैयार-core चयनकर्ताओं की मरम्मत अनुमोदित क्रेडेंशियल-पृथक टूलिंग के माध्यम से करें; OIDC स्रोत उन्हें बदल नहीं सकता। अपरिवर्तनीय संस्करण को कभी दोबारा प्रकाशित न करें। GHCR और Docker Hub में सटीक डिफ़ॉल्ट, slim, browser और आर्किटेक्चर इमेज, उनके सत्यापन और प्लेटफ़ॉर्म संस्करण सहित, सत्यापित करने के लिए Docker Release आवश्यक करें। इसे डाइजेस्ट द्वारा केवल extended-stable, extended-stable-slim और extended-stable-browser को आगे बढ़ाना चाहिए; नियमित उपनाम अपरिवर्तित रहते हैं और स्वचालित रोलबैक अस्वीकार किया जाता है। उपनाम सुधार के लिए, वर्तमान main से टैग के साथ अनुमोदन-गेटेड Docker Channel Promotion चलाएँ। यह डाइजेस्ट, सत्यापन और प्लेटफ़ॉर्म जाँच दोहराता है, स्पष्ट रोलबैक की अनुमति देता है और इमेज को कभी दोबारा बिल्ड नहीं करता। Slack, Discord और Codex आरंभिक दस्तावेज़ीकृत समर्थन सतहें हैं, रिलीज़ अनुमति-सूची नहीं: npm पर प्रकाशित किया जा सकने वाला प्रत्येक आधिकारिक plugin जारी होता है। केवल नियमित चेकलिस्ट beta/latest, GitHub Releases, ClawHub, नेटिव ऐप, मोबाइल, वेबसाइट और निजी dist-tags की स्वामी है; इस Gateway पथ के लिए वे चरण न चलाएँ।

नियमित रिलीज़ ऑपरेटर चेकलिस्ट

यह चेकलिस्ट रिलीज़ प्रवाह का सार्वजनिक स्वरूप है। निजी क्रेडेंशियल, हस्ताक्षर, नोटराइज़ेशन, dist-tag पुनर्प्राप्ति और आपातकालीन रोलबैक विवरण केवल अनुरक्षकों की रिलीज़ रनबुक में रहते हैं।

वर्तमान main से शुरू करें: नवीनतम बदलाव पुल करें, पुष्टि करें कि लक्ष्य कमिट पुश किया गया है और पुष्टि करें कि main CI शाखा बनाने के लिए पर्याप्त रूप से हरा है।
उस कमिट से release/YYYY.M.PATCH बनाएँ। बैकपोर्ट वैकल्पिक हैं; केवल ऑपरेटर द्वारा चुना गया सेट लागू करें। प्रत्येक आवश्यक संस्करण स्थान को बढ़ाएँ, pnpm release:prep चलाएँ, रिलीज़ सुधार और आवश्यक फ़ॉरवर्ड-पोर्ट पूरे करें तथा src/plugins/compat/registry.ts और src/commands/doctor/shared/deprecation-compat.ts की समीक्षा करें।
उत्पाद-पूर्ण, चेंजलॉग-पूर्व कमिट को Code SHA के रूप में फ़्रीज़ करें। निर्धारक स्रोत प्रीफ़्लाइट चलाएँ, फिर node scripts/full-release-validation-at-sha.mjs --sha <code-sha> --target-ref release/YYYY.M.PATCH उपयोग करें। यह विश्वसनीय वर्कफ़्लो टूलिंग को पिन करता है, जबकि पूर्ण Vitest, Docker, QA, पैकेज और प्रदर्शन मैट्रिक्स सटीक Code SHA को लक्षित करता है।
संपादन से पहले विफलताओं को वर्गीकृत करें। उत्पाद/कोड विफलता नया Code SHA बनाती है और उस SHA के लिए सफल पूर्ण सत्यापन आवश्यक करती है। वर्कफ़्लो, हार्नेस, क्रेडेंशियल, अनुमोदन या इन्फ़्रास्ट्रक्चर विफलता की मरम्मत उसकी स्वामी सतह में की जाती है और उसी Code SHA के विरुद्ध फिर से चलाई जाती है।
Code SHA सफल होने के बाद ही, अंतिम पहुँच-योग्य जारी किए गए टैग के बाद से मर्ज किए गए PR और सीधे कमिट से शीर्ष CHANGELOG.md अनुभाग जनरेट करें। प्रविष्टियों को उपयोगकर्ता-सामना करने वाला और डुप्लिकेट-रहित रखें। जब कोई भिन्न जारी किया गया टैग या बाद का फ़ॉरवर्ड-पोर्ट पहले से जारी PR को पुनः संबद्ध करता है, तो उसे स्पष्ट रूप से --shipped-ref के रूप में पास करें।
केवल CHANGELOG.md कमिट करें। यह कमिट Release SHA है। Code SHA से Release SHA तक का पूर्ण अंतर ठीक CHANGELOG.md होना चाहिए; कोई अन्य बदला हुआ पथ रिलीज़ को चरण 2 पर लौटा देता है।
साक्ष्य पुनः उपयोग सक्षम रखते हुए Release SHA के लिए SHA-पिन किया गया पूर्ण रिलीज़ सत्यापन चलाएँ। हल्के पैरेंट को changelog-only-release-v1 दर्ज करना चाहिए, सफल Code SHA की ओर संकेत करना चाहिए और कोई उत्पाद चाइल्ड लेन डिस्पैच नहीं करनी चाहिए। यह उत्पाद साक्ष्य का पुनः उपयोग करता है; पैकेज बाइट्स का नहीं।
Release SHA/टैग के विरुद्ध preflight_only=true के साथ OpenClaw NPM Release चलाएँ। सफल preflight_run_id सहेजें। यह अंतिम चेंजलॉग वाले सटीक पैकेज बाइट्स को बिल्ड और जाँचता है।
Release SHA को टैग करें, फिर दोनों को दोबारा डिस्पैच करने के बजाय सफल Release-SHA सत्यापन पैरेंट और npm प्रीफ़्लाइट के साथ उम्मीदवार हेल्पर चलाएँ:
pnpm release:candidate -- \ --tag vYYYY.M.PATCH-beta.N \ --full-release-run <release-sha-validation-run-id> \ --npm-preflight-run <preflight-run-id> \ --skip-dispatch
स्थिर रिलीज़ के लिए, --windows-node-tag vX.Y.Z भी पास करें। सहायक रिलीज़ नोट की उत्पत्ति, npm प्रीफ़्लाइट बाइट्स, Parallels इंस्टॉल/अपडेट प्रमाण, Telegram पैकेज प्रमाण और plugin प्रकाशन योजनाओं को सत्यापित करता है, फिर प्रकाशन कमांड प्रिंट करता है। OpenClaw Release Publish चुने गए या प्रकाशन-योग्य सभी plugin पैकेजों को npm पर और समान सेट को ClawHub पर समानांतर रूप से डिस्पैच करता है, फिर plugin का npm प्रकाशन सफल होने पर तैयार OpenClaw npm प्रीफ़्लाइट आर्टिफ़ैक्ट को मेल खाते dist-tag के साथ प्रमोट करता है। रिलीज़ चेकआउट उत्पाद/डेटा रूट बना रहता है, जबकि योजना और अंतिम सत्यापन सटीक विश्वसनीय वर्कफ़्लो-स्रोत चेकआउट से निष्पादित होते हैं, ताकि कोई पुराना रिलीज़ कमिट चुपचाप अप्रचलित रिलीज़ टूलिंग का उपयोग न कर सके। कोई भी प्रकाशन चाइल्ड शुरू होने से पहले, यह सटीक GitHub रिलीज़ बॉडी रेंडर करके कैश करता है। जब पूरा मेल खाता CHANGELOG.md अनुभाग GitHub की 125,000-अक्षर सीमा और रेंडरर की मेल खाती 125,000-बाइट सुरक्षा सीमा में समा जाता है, तो पृष्ठ में उसके शीर्षक सहित वही सटीक ## YYYY.M.PATCH अनुभाग होता है। जब स्रोत अनुभाग समाता नहीं है, तो पृष्ठ सटीक समूहीकृत संपादकीय नोट बनाए रखता है और अत्यधिक बड़े योगदान रिकॉर्ड को टैग-पिन किए गए CHANGELOG.md में पूर्ण रिकॉर्ड की स्थायी लिंक से बदल देता है; आंशिक रिकॉर्ड और काटे गए बुलेट कभी प्रकाशित नहीं किए जाते। वर्कफ़्लो ### Release verification जोड़ने से पहले उस पूर्ण या संक्षिप्त बॉडी को चुनता है; यदि प्रमाण का अंतिम भाग सीमा पार कर देगा, तो यह प्रामाणिक बॉडी बनाए रखता है और इसके बजाय अपरिवर्तनीय संलग्न साक्ष्य पर निर्भर करता है। npm latest पर प्रकाशित स्थिर रिलीज़ GitHub की नवीनतम रिलीज़ बन जाती हैं, जबकि npm beta पर रखी गई स्थिर रखरखाव रिलीज़ GitHub latest=false के साथ बनाई जाती हैं। वर्कफ़्लो रिलीज़ के बाद की घटना-प्रतिक्रिया के लिए प्रीफ़्लाइट निर्भरता साक्ष्य, पूर्ण-सत्यापन मेनिफ़ेस्ट और प्रकाशन-पश्चात रजिस्ट्री सत्यापन साक्ष्य भी GitHub रिलीज़ पर अपलोड करता है। यह चाइल्ड रन ID तुरंत प्रिंट करता है, उन रिलीज़ परिवेश गेट को स्वतः अनुमोदित करता है जिन्हें वर्कफ़्लो टोकन अनुमोदित कर सकता है, विफल चाइल्ड जॉब का लॉग के अंतिम भाग सहित सारांश देता है, ड्राफ़्ट GitHub रिलीज़ पृष्ठ पहले ही बना देता है और OpenClaw npm प्रकाशन के साथ-साथ Windows तथा Android आर्टिफ़ैक्ट प्रमोट करता है, उन चरणों की सफलता के बाद रिलीज़ पृष्ठ और निर्भरता साक्ष्य को अंतिम रूप देता है, जब भी OpenClaw npm प्रकाशित हो रहा हो तब ClawHub की प्रतीक्षा करता है, फिर विश्वसनीय-main बीटा सत्यापक चलाता है और GitHub रिलीज़, npm पैकेज, चुने गए plugin npm पैकेज, चुने गए ClawHub पैकेज, चाइल्ड वर्कफ़्लो रन ID और वैकल्पिक NPM Telegram रन ID के लिए प्रकाशन-पश्चात साक्ष्य अपलोड करता है। ClawHub बूटस्ट्रैप सत्यापक के लिए सटीक विश्वसनीय-main वर्कफ़्लो पथ और SHA, उत्पादक और टर्मिनल रन प्रयास, रिलीज़ SHA, अनुरोधित पैकेज सेट, अपरिवर्तनीय पैकेज आर्टिफ़ैक्ट ट्यूपल और टर्मिनल रजिस्ट्री रीडबैक आर्टिफ़ैक्ट आवश्यक हैं; सफल लेगेसी रिलीज़-ref रन स्वीकार नहीं किया जाता। फिर प्रकाशित openclaw@YYYY.M.PATCH-beta.N या openclaw@beta पैकेज के विरुद्ध प्रकाशन-पश्चात पैकेज स्वीकृति चलाएँ। यदि पुश या प्रकाशित की गई प्रीरिलीज़ में सुधार की आवश्यकता हो, तो अगली मेल खाती प्रीरिलीज़ संख्या जारी करें; पुरानी संख्या को कभी हटाएँ या दोबारा न लिखें।
विफल प्रकाशन प्रयास पर, Release SHA को अपरिवर्तित रखें, जब तक कि विफलता किसी उत्पाद या चेंजलॉग दोष को सिद्ध न करे। सफल अपरिवर्तनीय चाइल्ड और आर्टिफ़ैक्ट फिर से शुरू करें; पहले से सफल हो चुके पैकेज संस्करण को कभी दोबारा बिल्ड या प्रकाशित न करें।
स्थिर रिलीज़ के लिए, केवल तभी आगे बढ़ें जब जाँचे गए बीटा या रिलीज़ कैंडिडेट के पास आवश्यक सत्यापन साक्ष्य हों। स्थिर npm प्रकाशन भी OpenClaw Release Publish से होकर जाता है और preflight_run_id के माध्यम से सफल प्रीफ़्लाइट आर्टिफ़ैक्ट का पुनः उपयोग करता है। स्थिर macOS रिलीज़ तत्परता के लिए पैकेज किए गए .zip, .dmg, .dSYM.zip और main पर अपडेट किया हुआ appcast.xml भी आवश्यक है; रिलीज़ आर्टिफ़ैक्ट सत्यापित होने के बाद macOS प्रकाशन वर्कफ़्लो हस्ताक्षरित appcast को सार्वजनिक main पर स्वचालित रूप से प्रकाशित करता है, या यदि ब्रांच सुरक्षा सीधे पुश को रोकती है तो appcast PR खोलता/अपडेट करता है। स्थिर Windows Hub तत्परता के लिए OpenClaw GitHub रिलीज़ पर हस्ताक्षरित OpenClawCompanion-Setup-x64.exe, OpenClawCompanion-Setup-arm64.exe और OpenClawCompanion-SHA256SUMS.txt आर्टिफ़ैक्ट आवश्यक हैं। सटीक हस्ताक्षरित openclaw/openclaw-windows-node रिलीज़ टैग को windows_node_tag और उसके कैंडिडेट-अनुमोदित इंस्टॉलर डाइजेस्ट मैप को windows_node_installer_digests के रूप में पास करें; OpenClaw Release Publish रिलीज़ ड्राफ़्ट बनाए रखता है, Windows Node Release डिस्पैच करता है और प्रकाशन से पहले तीनों आर्टिफ़ैक्ट सत्यापित करता है।
प्रकाशन के बाद, npm प्रकाशन-पश्चात सत्यापक, प्रकाशन-पश्चात चैनल प्रमाण की आवश्यकता होने पर वैकल्पिक स्वतंत्र प्रकाशित-npm Telegram E2E, आवश्यकता होने पर dist-tag प्रमोशन चलाएँ, जनरेट किए गए GitHub रिलीज़ पृष्ठ को सत्यापित करें, रिलीज़ घोषणा चरण चलाएँ, फिर स्थिर रिलीज़ को पूर्ण कहने से पहले स्थिर main समापन पूरा करें।

स्थिर main समापन

स्थिर प्रकाशन तब तक पूरा नहीं होता, जब तक main में वास्तव में शिप की गई रिलीज़ स्थिति मौजूद न हो।

नवीनतम ताज़ा main से शुरू करें। उसके विरुद्ध release/YYYY.M.PATCH का ऑडिट करें और main में अनुपस्थित वास्तविक सुधारों को फ़ॉरवर्ड-पोर्ट करें। केवल रिलीज़ के लिए बने संगतता, परीक्षण या सत्यापन अडैप्टर को नए main में आँख मूँदकर मर्ज न करें।
सामान्य पथ के लिए, main को शिप किए गए स्थिर संस्करण पर सेट करें। विलंबित समापन में main का उपयोग किया जा सकता है, जब वह बाद के स्थिर OpenClaw CalVer तक आगे बढ़ चुका हो; केवल पिछली रिलीज़ का समापन करने के लिए पहले से शुरू रिलीज़ क्रम को डाउनग्रेड न करें। सत्यापक को फिर भी शिप किए गए सटीक चेंजलॉग अनुभाग और appcast प्रविष्टि की आवश्यकता होती है तथा वह वास्तविक main संस्करण और SHA रिकॉर्ड करता है। किसी भी रूट संस्करण परिवर्तन के बाद pnpm release:prep, फिर pnpm deps:shrinkwrap:generate चलाएँ।
main पर CHANGELOG.md के ## YYYY.M.PATCH अनुभाग को टैग की गई रिलीज़ ब्रांच से बिल्कुल मेल कराएँ। यदि mac रिलीज़ ने स्थिर appcast.xml अपडेट प्रकाशित किया है, तो उसे शामिल करें।
ऑपरेटर द्वारा उस रिलीज़ क्रम को स्पष्ट रूप से शुरू किए जाने तक main में YYYY.M.PATCH+1, बीटा संस्करण या भविष्य का खाली चेंजलॉग अनुभाग न जोड़ें।
pnpm release:generated:check, pnpm deps:shrinkwrap:check और OPENCLAW_TESTBOX=1 pnpm check:changed चलाएँ। पुश करें, फिर स्थिर रिलीज़ को पूर्ण कहने से पहले सत्यापित करें कि origin/main में शिप किया गया संस्करण और चेंजलॉग मौजूद हैं।
प्रत्येक निजी रोलबैक अभ्यास के बाद रिपॉज़िटरी चर RELEASE_ROLLBACK_DRILL_ID और RELEASE_ROLLBACK_DRILL_DATE को वर्तमान रखें।

OpenClaw Stable Main Closeout स्थिर प्रकाशन के बाद उस main पुश से शुरू होता है जिसमें शिप किया गया संस्करण, चेंजलॉग और appcast होते हैं। यह शिप किए गए टैग को उसके पूर्ण रिलीज़ सत्यापन और प्रकाशन रन से बाँधने के लिए अपरिवर्तनीय प्रकाशन-पश्चात साक्ष्य पढ़ता है, फिर स्थिर main स्थिति, रिलीज़, अनिवार्य स्थिर सोक और अवरोधक प्रदर्शन साक्ष्य को सत्यापित करता है। यह GitHub रिलीज़ में अपरिवर्तनीय समापन मेनिफ़ेस्ट और चेकसम संलग्न करता है। स्वचालित पुश ट्रिगर अपरिवर्तनीय प्रकाशन-पश्चात साक्ष्य से पहले की लेगेसी रिलीज़ को छोड़ देता है और उस छोड़े जाने को कभी पूर्ण समापन नहीं मानता। पूर्ण समापन के लिए आर्टिफ़ैक्ट और मेल खाता चेकसम, दोनों आवश्यक हैं। आंशिक मेनिफ़ेस्ट समान बाइट्स दोबारा जनरेट करने के लिए अपने रिकॉर्ड किए गए main SHA और रोलबैक अभ्यास को फिर चलाता है, फिर अनुपस्थित चेकसम संलग्न करता है; अमान्य जोड़ी या मेनिफ़ेस्ट के बिना चेकसम अवरोधक बना रहता है। रोलबैक अभ्यास रिपॉज़िटरी चर के बिना पुश-ट्रिगर किया गया रन समापन पूरा किए बिना छोड़ दिया जाता है; अनुपस्थित या 90 दिन से अधिक पुराना अभ्यास रिकॉर्ड मैनुअल साक्ष्य-समर्थित समापन को भी रोकता है। निजी पुनर्प्राप्ति कमांड केवल मेंटेनर वाले रनबुक में रहते हैं। मैनुअल डिस्पैच का उपयोग केवल साक्ष्य-समर्थित स्थिर समापन की मरम्मत या पुनः संचालन के लिए करें। यदि Release Publish पैरेंट केवल अपरिवर्तनीय npm/plugin साक्ष्य संलग्न होने के बाद विफल हुआ हो, तो पहले प्रत्येक स्थिर प्लेटफ़ॉर्म आर्टिफ़ैक्ट की मरम्मत करके प्रकाशित करें। फिर कोई मेंटेनर allow_failed_publish_recovery=true के साथ समापन को मैनुअल रूप से डिस्पैच कर सकता है; यह मोड केवल पूर्ण हो चुके विफल पैरेंट को स्वीकार करता है और सामान्य macOS/appcast जाँचों के साथ-साथ सटीक Android तथा Windows आर्टिफ़ैक्ट अनुबंध, GitHub SHA-256 डाइजेस्ट, चेकसम सत्यापन, Android उत्पत्ति और सफल पैरेंट-डिस्पैच Windows प्रमोशन भी आवश्यक करता है, जिसकी Authenticode जाँच और कैंडिडेट-अनुमोदित डाइजेस्ट प्रकाशित इंस्टॉलर से मेल खाते हों। स्वचालित पुश समापन इस पुनर्प्राप्ति मोड को कभी सक्षम नहीं करता। लेगेसी फ़ॉलबैक सुधार टैग केवल तभी बेस-पैकेज साक्ष्य का पुनः उपयोग कर सकता है, जब सुधार टैग उसी स्रोत कमिट पर रिज़ॉल्व हो जिस पर बेस स्थिर टैग होता है। उसकी Android रिलीज़ बेस टैग के सत्यापित APK का पुनः उपयोग करती है और सुधार टैग के लिए उत्पत्ति जोड़ती है। अलग स्रोत वाले सुधार को अपना पैकेज साक्ष्य प्रकाशित और सत्यापित करना होगा तथा अधिक Android versionCode का उपयोग करना होगा।

रिलीज़ प्रीफ़्लाइट

रिलीज़ प्रीफ़्लाइट से पहले pnpm check:test-types चलाएँ, ताकि परीक्षण TypeScript तेज़ स्थानीय pnpm check गेट के बाहर भी कवर्ड रहे।
रिलीज़ प्रीफ़्लाइट से पहले pnpm check:architecture चलाएँ, ताकि अधिक व्यापक इंपोर्ट साइकल और आर्किटेक्चर सीमा जाँचें तेज़ स्थानीय गेट के बाहर सफल रहें।
pnpm release:check से पहले pnpm build && pnpm ui:build चलाएँ, ताकि पैक सत्यापन चरण के लिए अपेक्षित dist/* रिलीज़ आर्टिफ़ैक्ट और Control UI बंडल मौजूद हों।
रूट संस्करण बढ़ाने के बाद और टैग करने से पहले pnpm release:prep चलाएँ। यह प्रत्येक नियतात्मक रिलीज़ जनरेटर चलाता है जिसमें संस्करण/config/API परिवर्तन के बाद सामान्यतः अंतर आ जाता है: plugin संस्करण, npm shrinkwrap, plugin इन्वेंटरी, बेस config स्कीमा, बंडल किए गए चैनल config मेटाडेटा, config दस्तावेज़ बेसलाइन, plugin SDK एक्सपोर्ट, Plugin SDK API अनुबंध मेनिफ़ेस्ट और Control UI लोकेल बंडल। यह तब तक अवरोधित भी करता है, जब तक नेटिव ऐप अनुवाद और प्लेटफ़ॉर्म-जनरेट किए गए लोकेल संसाधन स्रोत इन्वेंटरी से मेल न खाएँ; यदि वे पीछे हों, तो Code SHA को फ़्रीज़ करने से पहले Native App Locale Refresh की प्रतीक्षा करें या उसे डिस्पैच करें। pnpm release:check उन गार्ड को जाँच मोड में दोबारा चलाता है—जिसमें सख्त लोकेल गेट और plugin SDK सतह बजट शामिल हैं—और पैकेज रिलीज़ जाँच चलाने से पहले एक ही पास में जनरेट किए गए सभी अंतर की विफलताओं की रिपोर्ट करता है।
Plugin संस्करण सिंक डिफ़ॉल्ट रूप से प्रकाशन-योग्य @openclaw/ai रनटाइम पैकेज, आधिकारिक plugin पैकेज संस्करणों और मौजूदा openclaw.compat.pluginApi न्यूनतम सीमाओं को OpenClaw रिलीज़ संस्करण पर अपडेट करता है। उस फ़ील्ड को केवल पैकेज संस्करण की प्रति नहीं, बल्कि plugin SDK/रनटाइम API की न्यूनतम सीमा मानें: उन केवल-plugin रिलीज़ के लिए जो जानबूझकर पुराने OpenClaw होस्ट के साथ संगत रहती हैं, न्यूनतम सीमा को सबसे पुराने समर्थित होस्ट API पर रखें और उस चयन को plugin रिलीज़ प्रमाण में दर्ज करें।
एक ही प्रवेश बिंदु से सभी प्रीरिलीज़ टेस्ट बॉक्स शुरू करने के लिए रिलीज़ अनुमोदन से पहले मैनुअल Full Release Validation वर्कफ़्लो चलाएँ। यह ब्रांच, टैग या पूरा कमिट SHA स्वीकार करता है, मैनुअल CI डिस्पैच करता है और इंस्टॉल स्मोक, पैकेज स्वीकृति, क्रॉस-OS पैकेज जाँच, QA Lab समानता, Matrix तथा Telegram लेन के लिए OpenClaw Release Checks डिस्पैच करता है। स्थिर और पूर्ण रन में हमेशा विस्तृत लाइव/E2E और Docker रिलीज़-पथ सोक शामिल होते हैं; run_release_soak=true स्पष्ट बीटा सोक के लिए रखा गया है। पैकेज स्वीकृति कैंडिडेट सत्यापन के दौरान प्रामाणिक पैकेज Telegram E2E प्रदान करती है, जिससे दूसरे समवर्ती लाइव पोलर की आवश्यकता नहीं रहती। रिलीज़ टारबॉल को दोबारा बिल्ड किए बिना रिलीज़ जाँच, पैकेज स्वीकृति और पैकेज Telegram E2E में शिप किए गए npm पैकेज का पुनः उपयोग करने के लिए बीटा प्रकाशित करने के बाद release_package_spec प्रदान करें। केवल तभी npm_telegram_package_spec प्रदान करें, जब Telegram को शेष रिलीज़ सत्यापन से अलग प्रकाशित पैकेज का उपयोग करना हो। जब पैकेज स्वीकृति को रिलीज़ पैकेज विनिर्देश से अलग प्रकाशित पैकेज का उपयोग करना हो, तब package_acceptance_package_spec प्रदान करें। जब रिलीज़ साक्ष्य रिपोर्ट को Telegram E2E अनिवार्य किए बिना यह सिद्ध करना हो कि सत्यापन प्रकाशित npm पैकेज से मेल खाता है, तब evidence_package_spec प्रदान करें।
node scripts/full-release-validation-at-sha.mjs \ --sha <code-sha> \ --target-ref release/YYYY.M.PATCH
जब रिलीज़ कार्य जारी हो और आपको किसी पैकेज उम्मीदवार के लिए साइड-चैनल प्रमाण चाहिए, तब मैन्युअल Package Acceptance वर्कफ़्लो चलाएँ। openclaw@beta, openclaw@latest, या किसी सटीक रिलीज़ संस्करण के लिए source=npm का उपयोग करें; वर्तमान workflow_ref हार्नेस के साथ किसी विश्वसनीय package_ref ब्रांच/टैग/SHA को पैक करने के लिए source=ref; आवश्यक SHA-256 और सख्त सार्वजनिक URL नीति वाली सार्वजनिक HTTPS टारबॉल के लिए source=url; आवश्यक trusted_source_id और SHA-256 का उपयोग करने वाली नामित विश्वसनीय-स्रोत नीति के लिए source=trusted-url; या किसी अन्य GitHub Actions रन द्वारा अपलोड की गई टारबॉल के लिए source=artifact का उपयोग करें। वर्कफ़्लो उम्मीदवार को package-under-test में हल करता है, उस टारबॉल के विरुद्ध Docker E2E रिलीज़ शेड्यूलर का पुनः उपयोग करता है, और telegram_mode=mock-openai या telegram_mode=live-frontier के साथ उसी टारबॉल के विरुद्ध Telegram QA चला सकता है। जब चयनित Docker लेन में published-upgrade-survivor शामिल होता है, तो पैकेज आर्टिफ़ैक्ट उम्मीदवार होता है और published_upgrade_survivor_baseline प्रकाशित बेसलाइन चुनता है। update-restart-auth उम्मीदवार पैकेज का उपयोग इंस्टॉल किए गए CLI और परीक्षणाधीन पैकेज, दोनों के रूप में करता है, ताकि यह उम्मीदवार अपडेट कमांड के प्रबंधित रीस्टार्ट पथ का परीक्षण करे। उदाहरण:
gh workflow run package-acceptance.yml --ref main -f workflow_ref=main -f source=npm -f package_spec=openclaw@beta -f suite_profile=product -f published_upgrade_survivor_baseline=openclaw@2026.4.26 -f telegram_mode=mock-openai
सामान्य प्रोफ़ाइल:
- smoke: इंस्टॉल/चैनल/एजेंट, Gateway नेटवर्क और कॉन्फ़िगरेशन रीलोड लेन
- package: OpenWebUI या लाइव ClawHub के बिना आर्टिफ़ैक्ट-नेटिव पैकेज/अपडेट/रीस्टार्ट/Plugin लेन
- product: पैकेज प्रोफ़ाइल के साथ MCP चैनल, cron/सबएजेंट क्लीनअप, OpenAI वेब खोज और OpenWebUI
- full: OpenWebUI के साथ Docker रिलीज़-पथ खंड
- custom: केंद्रित पुनः रन के लिए सटीक docker_lanes चयन
जब आपको रिलीज़ उम्मीदवार के लिए केवल निर्धारक सामान्य CI कवरेज चाहिए, तब मैन्युअल CI वर्कफ़्लो सीधे चलाएँ। मैन्युअल CI डिस्पैच परिवर्तित स्कोपिंग को बायपास करते हैं और Linux Node शार्ड, बंडल किए गए Plugin शार्ड, Plugin और चैनल अनुबंध शार्ड, Node 22 संगतता, check-*, check-additional-*, निर्मित-आर्टिफ़ैक्ट स्मोक जाँच, दस्तावेज़ जाँच, Python Skills, Windows, macOS और Control UI i18n लेन को अनिवार्य रूप से चलाते हैं। स्टैंडअलोन मैन्युअल CI Android को केवल include_android=true के साथ डिस्पैच किए जाने पर चलाता है; Full Release Validation अपने CI चाइल्ड को वह इनपुट भेजता है।
gh workflow run ci.yml --ref release/YYYY.M.PATCH -f include_android=true
रिलीज़ टेलीमेट्री सत्यापित करते समय pnpm qa:otel:smoke चलाएँ। यह स्थानीय OTLP/HTTP रिसीवर के माध्यम से QA-lab का परीक्षण करता है और Opik, Langfuse या किसी अन्य बाहरी कलेक्टर की आवश्यकता के बिना ट्रेस, मेट्रिक और लॉग निर्यात के साथ सीमित ट्रेस एट्रिब्यूट तथा सामग्री/पहचानकर्ता रिडैक्शन सत्यापित करता है।
कलेक्टर संगतता सत्यापित करते समय pnpm qa:otel:collector-smoke चलाएँ। यह स्थानीय रिसीवर अभिकथनों से पहले उसी QA-lab OTLP निर्यात को वास्तविक OpenTelemetry Collector Docker कंटेनर के माध्यम से रूट करता है।
संरक्षित Prometheus स्क्रैपिंग सत्यापित करते समय pnpm qa:prometheus:smoke चलाएँ। यह QA-lab का परीक्षण करता है, अप्रमाणित स्क्रैप अस्वीकार करता है और सत्यापित करता है कि रिलीज़-महत्वपूर्ण मेट्रिक परिवार प्रॉम्प्ट सामग्री, अपरिष्कृत पहचानकर्ताओं, प्रमाणीकरण टोकन और स्थानीय पथों से मुक्त रहें।
स्रोत-चेकआउट OpenTelemetry और Prometheus स्मोक लेन को लगातार चलाने के लिए pnpm qa:observability:smoke चलाएँ।
प्रत्येक टैग की गई रिलीज़ से पहले pnpm release:check चलाएँ।
OpenClaw NPM Release प्रीफ़्लाइट npm टारबॉल पैक करने से पहले निर्भरता रिलीज़ प्रमाण उत्पन्न करता है। npm एडवाइज़री भेद्यता गेट रिलीज़ को अवरुद्ध करता है। ट्रांज़िटिव मैनिफ़ेस्ट जोखिम, निर्भरता स्वामित्व/इंस्टॉल सतह और निर्भरता परिवर्तन रिपोर्ट केवल रिलीज़ प्रमाण हैं। निर्भरता परिवर्तन रिपोर्ट रिलीज़ उम्मीदवार की तुलना पिछले पहुँच योग्य रिलीज़ टैग से करती है। प्रीफ़्लाइट निर्भरता प्रमाण को openclaw-release-dependency-evidence-<tag> के रूप में अपलोड करता है और उसे तैयार किए गए npm प्रीफ़्लाइट आर्टिफ़ैक्ट के अंदर dependency-evidence/ के अंतर्गत भी एम्बेड करता है। वास्तविक प्रकाशन पथ उस प्रीफ़्लाइट आर्टिफ़ैक्ट का पुनः उपयोग करता है, फिर उसी प्रमाण को GitHub रिलीज़ में openclaw-<version>-dependency-evidence.zip के रूप में संलग्न करता है।
टैग मौजूद होने के बाद परिवर्तनकारी प्रकाशन क्रम के लिए OpenClaw Release Publish चलाएँ। नियमित बीटा और स्थिर प्रकाशन विश्वसनीय main से डिस्पैच करें; रिलीज़ टैग फिर भी सटीक लक्ष्य कमिट चुनता है और release/YYYY.M.PATCH को इंगित कर सकता है। Tideclaw अल्फ़ा प्रकाशन अपनी संगत अल्फ़ा ब्रांच पर बने रहते हैं। सफल OpenClaw npm preflight_run_id, सफल full_release_validation_run_id और सटीक full_release_validation_run_attempt पास करें तथा डिफ़ॉल्ट Plugin प्रकाशन स्कोप all-publishable बनाए रखें, जब तक कि आप जानबूझकर केंद्रित मरम्मत न चला रहे हों। वर्कफ़्लो Plugin npm प्रकाशन, Plugin ClawHub प्रकाशन और OpenClaw npm प्रकाशन को क्रमबद्ध करता है, ताकि कोर पैकेज उसके बाह्यकृत Plugin से पहले प्रकाशित न हो; Windows और Android प्रमोशन ड्राफ़्ट रिलीज़ पृष्ठ के विरुद्ध कोर npm प्रकाशन के साथ-साथ चलता है। प्रकाशन के पुनः रन फिर से शुरू किए जा सकते हैं: पहले से प्रकाशित कोर npm संस्करण के लिए वर्कफ़्लो द्वारा यह सिद्ध करने के बाद कि रजिस्ट्री टारबॉल टैग के प्रीफ़्लाइट आर्टिफ़ैक्ट से मेल खाती है, कोर डिस्पैच छोड़ दिया जाता है; और जब रिलीज़ में सत्यापित एसेट अनुबंध पहले से मौजूद हो, तब Windows/Android प्रमोशन छोड़ दिया जाता है, इसलिए पुनः प्रयास केवल विफल चरणों को दोहराता है। केंद्रित केवल-Plugin मरम्मत के लिए plugin_publish_scope=selected और एक गैर-रिक्त Plugin सूची आवश्यक है। केवल-Plugin all-publishable रन के लिए पूर्ण अपरिवर्तनीय प्रीफ़्लाइट और पूर्ण रिलीज़ सत्यापन प्रमाण आवश्यक है; आंशिक प्रमाण अस्वीकार किया जाता है।
स्थिर OpenClaw Release Publish के लिए संगत गैर-प्रीरिलीज़ openclaw/openclaw-windows-node रिलीज़ के मौजूद होने के बाद सटीक windows_node_tag और उम्मीदवार-अनुमोदित windows_node_installer_digests मैप आवश्यक है। किसी भी प्रकाशन चाइल्ड को डिस्पैच करने से पहले, यह सत्यापित करता है कि स्रोत रिलीज़ प्रकाशित और गैर-प्रीरिलीज़ है, उसमें आवश्यक x64/ARM64 इंस्टॉलर मौजूद हैं और वह अभी भी उस अनुमोदित मैप से मेल खाती है। इसके बाद, जब OpenClaw रिलीज़ अभी भी ड्राफ़्ट होती है, यह पिन किए गए इंस्टॉलर डाइजेस्ट मैप को अपरिवर्तित रखते हुए Windows Node Release डिस्पैच करता है। चाइल्ड वर्कफ़्लो उसी सटीक टैग से हस्ताक्षरित Windows Hub इंस्टॉलर डाउनलोड करता है, उन्हें पिन किए गए डाइजेस्ट से मिलाता है, Windows रनर पर सत्यापित करता है कि उनके Authenticode हस्ताक्षर अपेक्षित OpenClaw Foundation हस्ताक्षरकर्ता का उपयोग करते हैं, SHA-256 मैनिफ़ेस्ट लिखता है और इंस्टॉलर तथा मैनिफ़ेस्ट को प्रामाणिक OpenClaw GitHub रिलीज़ पर अपलोड करता है; फिर प्रचारित एसेट दोबारा डाउनलोड करके मैनिफ़ेस्ट सदस्यता और हैश सत्यापित करता है। पैरेंट प्रकाशन से पहले वर्तमान x64, ARM64 और चेकसम एसेट अनुबंध सत्यापित करता है। प्रत्यक्ष पुनर्प्राप्ति अपेक्षित अनुबंध एसेट को पिन किए गए स्रोत बाइट से बदलने से पहले अनपेक्षित OpenClawCompanion-* एसेट नाम अस्वीकार करती है। केवल पुनर्प्राप्ति के लिए Windows Node Release को मैन्युअल रूप से डिस्पैच करें और हमेशा एक सटीक टैग पास करें, कभी भी latest नहीं, साथ ही अनुमोदित स्रोत रिलीज़ से स्पष्ट expected_installer_digests JSON मैप पास करें। वेबसाइट डाउनलोड लिंक वर्तमान स्थिर रिलीज़ के लिए सटीक OpenClaw रिलीज़ एसेट URL को लक्षित करने चाहिए, या केवल यह सत्यापित करने के बाद releases/latest/download/... को कि GitHub का नवीनतम रीडायरेक्ट उसी रिलीज़ को इंगित करता है; केवल सहायक रिपॉज़िटरी के रिलीज़ पृष्ठ से लिंक न करें।
रिलीज़ जाँच अब एक अलग मैन्युअल वर्कफ़्लो में चलती हैं: OpenClaw Release Checks। यह रिलीज़ अनुमोदन से पहले QA Lab मॉक समतुल्यता लेन के साथ-साथ Matrix रिलीज़ प्रोफ़ाइल और Telegram QA लेन भी चलाता है। लाइव लेन qa-live-shared परिवेश का उपयोग करती हैं; Telegram, Convex CI क्रेडेंशियल लीज़ का भी उपयोग करता है। जब सभी अनुरक्षित Matrix परिदृश्य चाहिए हों, तो मैन्युअल QA-Lab - All Lanes वर्कफ़्लो को matrix_profile=all के साथ चलाएँ; वर्कफ़्लो उस चयन को ट्रांसपोर्ट, मीडिया और E2EE प्रोफ़ाइल में वितरित करता है, ताकि संपूर्ण प्रमाण प्रति-जॉब टाइमआउट के भीतर रहे।
क्रॉस-OS इंस्टॉल और अपग्रेड रनटाइम सत्यापन सार्वजनिक OpenClaw Release Checks और Full Release Validation का भाग है, जो पुनः उपयोग योग्य वर्कफ़्लो .github/workflows/openclaw-cross-os-release-checks-reusable.yml को सीधे कॉल करते हैं। यह विभाजन जानबूझकर किया गया है: वास्तविक npm रिलीज़ पथ को छोटा, नियतात्मक और आर्टिफ़ैक्ट-केंद्रित रखें, जबकि धीमी लाइव जाँच अपनी अलग लेन में रहें ताकि वे प्रकाशन को विलंबित या अवरुद्ध न करें।
सीक्रेट वाली रिलीज़ जाँच को Full Release Validation के माध्यम से या main/release वर्कफ़्लो रेफ़ से डिस्पैच किया जाना चाहिए, ताकि वर्कफ़्लो लॉजिक और सीक्रेट नियंत्रित रहें।
OpenClaw Release Checks किसी ब्रांच, टैग या पूर्ण कमिट SHA को स्वीकार करता है, बशर्ते समाधान किया गया कमिट किसी OpenClaw ब्रांच या रिलीज़ टैग से पहुँच योग्य हो।
OpenClaw NPM Release का केवल-सत्यापन प्रीफ़्लाइट, पुश किए गए टैग की आवश्यकता के बिना वर्तमान पूर्ण 40-वर्णीय वर्कफ़्लो-ब्रांच कमिट SHA को भी स्वीकार करता है। वह SHA पथ केवल सत्यापन के लिए है और उसे वास्तविक प्रकाशन में प्रमोट नहीं किया जा सकता। SHA मोड में वर्कफ़्लो केवल पैकेज मेटाडेटा जाँच के लिए v<package.json version> संश्लेषित करता है; वास्तविक प्रकाशन के लिए अब भी वास्तविक रिलीज़ टैग आवश्यक है।
दोनों वर्कफ़्लो वास्तविक प्रकाशन और प्रमोशन पथ को GitHub-होस्टेड रनर पर रखते हैं, जबकि गैर-परिवर्तनकारी सत्यापन पथ बड़े Blacksmith Linux रनर का उपयोग कर सकता है।
वह वर्कफ़्लो OPENAI_API_KEY और ANTHROPIC_API_KEY दोनों वर्कफ़्लो सीक्रेट का उपयोग करके OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache चलाता है।
npm रिलीज़ प्रीफ़्लाइट अब अलग रिलीज़ जाँच लेन की प्रतीक्षा नहीं करता।
स्थानीय रूप से रिलीज़ कैंडिडेट टैग करने से पहले, RELEASE_TAG=vYYYY.M.PATCH-beta.N pnpm release:fast-pretag-check चलाएँ। सहायक तेज़ रिलीज़ सुरक्षा-जाँच, Plugin npm/ClawHub रिलीज़ जाँच, बिल्ड, UI बिल्ड और release:openclaw:npm:check को उस क्रम में चलाता है जो GitHub प्रकाशन वर्कफ़्लो शुरू होने से पहले अनुमोदन रोकने वाली सामान्य गलतियों को पकड़ता है।
अनुमोदन से पहले RELEASE_TAG=vYYYY.M.PATCH node --import tsx scripts/openclaw-npm-release-check.ts (या अनुरूप प्रीरिलीज़/सुधार टैग) चलाएँ।
npm प्रकाशन के बाद, नई अस्थायी प्रीफ़िक्स में प्रकाशित रजिस्ट्री इंस्टॉल पथ सत्यापित करने के लिए node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.PATCH (या अनुरूप बीटा/सुधार संस्करण) चलाएँ।
बीटा प्रकाशन के बाद, साझा लीज़ किए गए Telegram क्रेडेंशियल पूल का उपयोग करके प्रकाशित npm पैकेज के विरुद्ध इंस्टॉल किए गए पैकेज की ऑनबोर्डिंग, Telegram सेटअप और वास्तविक Telegram E2E सत्यापित करने के लिए OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.PATCH-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live चलाएँ। स्थानीय मेंटेनर की एकबारगी जाँच Convex वेरिएबल छोड़ सकती है और तीन OPENCLAW_QA_TELEGRAM_* एनवायरनमेंट क्रेडेंशियल सीधे दे सकती है।
मेंटेनर मशीन से पूर्ण प्रकाशन-पश्चात बीटा स्मोक चलाने के लिए, pnpm release:beta-smoke -- --beta betaN का उपयोग करें। सहायक Parallels npm अपडेट/नए-लक्ष्य का सत्यापन चलाता है, NPM Telegram Beta E2E डिस्पैच करता है, सटीक वर्कफ़्लो रन को पोल करता है, आर्टिफ़ैक्ट डाउनलोड करता है और Telegram रिपोर्ट प्रिंट करता है।
मेंटेनर मैन्युअल NPM Telegram Beta E2E वर्कफ़्लो के माध्यम से GitHub Actions से वही प्रकाशन-पश्चात जाँच चला सकते हैं। यह जानबूझकर केवल मैन्युअल है और प्रत्येक मर्ज पर नहीं चलता।
मेंटेनर रिलीज़ स्वचालन प्रीफ़्लाइट-फिर-प्रमोट का उपयोग करता है:
- वास्तविक npm प्रकाशन को सफल npm preflight_run_id उत्तीर्ण करना अनिवार्य है।
- नियमित बीटा और स्थिर प्रकाशन का ऑर्केस्ट्रेशन और प्रीफ़्लाइट सटीक लक्ष्य टैग के विरुद्ध विश्वसनीय main का उपयोग करते हैं। Tideclaw अल्फ़ा प्रकाशन और प्रीफ़्लाइट अनुरूप अल्फ़ा ब्रांच का उपयोग करते हैं।
- स्थिर npm रिलीज़ डिफ़ॉल्ट रूप से beta का उपयोग करती हैं; स्थिर npm प्रकाशन वर्कफ़्लो इनपुट के माध्यम से स्पष्ट रूप से latest को लक्षित कर सकता है।
- टोकन-आधारित npm dist-tag परिवर्तन openclaw/releases/.github/workflows/openclaw-npm-dist-tags.yml में रहता है, क्योंकि npm dist-tag add को अब भी NPM_TOKEN की आवश्यकता है, जबकि स्रोत रिपॉज़िटरी केवल-OIDC प्रकाशन रखती है।
- सार्वजनिक macOS Release केवल सत्यापन के लिए है; जब कोई टैग केवल रिलीज़ ब्रांच पर हो, लेकिन वर्कफ़्लो main से डिस्पैच किया गया हो, तो public_release_branch=release/YYYY.M.PATCH सेट करें।
- वास्तविक macOS प्रकाशन को सफल macOS preflight_run_id और validate_run_id उत्तीर्ण करना अनिवार्य है।
- वास्तविक प्रकाशन पथ तैयार आर्टिफ़ैक्ट को दोबारा बनाने के बजाय प्रमोट करते हैं।
YYYY.M.PATCH-N जैसी स्थिर सुधार रिलीज़ के लिए, प्रकाशन-पश्चात सत्यापक YYYY.M.PATCH से YYYY.M.PATCH-N तक उसी अस्थायी-प्रीफ़िक्स अपग्रेड पथ की भी जाँच करता है, ताकि रिलीज़ सुधार पुराने वैश्विक इंस्टॉल को अनजाने में आधार स्थिर पेलोड पर न छोड़ें।
npm रिलीज़ प्रीफ़्लाइट तब तक विफल होकर बंद हो जाता है जब तक टारबॉल में dist/control-ui/index.html और गैर-रिक्त dist/control-ui/assets/ पेलोड दोनों शामिल न हों, ताकि हम फिर से खाली ब्राउज़र डैशबोर्ड शिप न करें।
प्रकाशन-पश्चात सत्यापन यह भी जाँचता है कि प्रकाशित Plugin एंट्रीपॉइंट और पैकेज मेटाडेटा इंस्टॉल किए गए रजिस्ट्री लेआउट में मौजूद हैं। अनुपस्थित Plugin रनटाइम पेलोड वाली रिलीज़ प्रकाशन-पश्चात सत्यापक में विफल होती है और उसे latest में प्रमोट नहीं किया जा सकता।
pnpm test:install:smoke कैंडिडेट अपडेट टारबॉल पर npm pack unpackedSize बजट भी लागू करता है, ताकि इंस्टॉलर e2e रिलीज़ प्रकाशन पथ से पहले अनजाने पैक आकार-वृद्धि को पकड़ ले।
यदि रिलीज़ कार्य ने CI योजना, एक्सटेंशन समय मैनिफ़ेस्ट या एक्सटेंशन परीक्षण मैट्रिक्स को प्रभावित किया है, तो अनुमोदन से पहले .github/workflows/plugin-prerelease.yml से प्लानर-स्वामित्व वाले plugin-prerelease-extension-shard मैट्रिक्स आउटपुट दोबारा जनरेट करके उनकी समीक्षा करें, ताकि रिलीज़ नोट पुराने CI लेआउट का वर्णन न करें।
स्थिर macOS रिलीज़ की तत्परता में अपडेटर सतहें भी शामिल हैं: GitHub रिलीज़ में अंततः पैकेज किए गए .zip, .dmg और .dSYM.zip होने चाहिए; main पर appcast.xml को प्रकाशन के बाद नई स्थिर zip की ओर इंगित करना चाहिए (macOS प्रकाशन वर्कफ़्लो इसे स्वतः कमिट करता है, या प्रत्यक्ष पुश अवरुद्ध होने पर appcast PR खोलता है); पैकेज किए गए ऐप में गैर-डिबग बंडल id, गैर-रिक्त Sparkle फ़ीड URL और उस रिलीज़ संस्करण के लिए प्रामाणिक Sparkle बिल्ड न्यूनतम सीमा के बराबर या उससे अधिक CFBundleVersion बना रहना चाहिए।

रिलीज़ परीक्षण बॉक्स

Full Release Validation वह तरीका है जिससे ऑपरेटर एक एंट्रीपॉइंट से पूर्ण उत्पाद मैट्रिक्स शुरू करते हैं। सहायक का उपयोग करें, ताकि प्रत्येक चाइल्ड वर्कफ़्लो एक विश्वसनीय main वर्कफ़्लो SHA पर स्थिर अस्थायी ब्रांच से चले, जबकि अनुरोधित कमिट परीक्षणाधीन कैंडिडेट बना रहे:

pnpm ci:full-release \
  --sha <code-sha> \
  --target-ref release/YYYY.M.PATCH

सहायक वर्तमान origin/main फ़ेच करता है, उस विश्वसनीय वर्कफ़्लो कमिट पर release-ci/<workflow-sha>-... पुश करता है, अल्फ़ा/बीटा पैकेज संस्करणों से beta और अन्यथा stable का अनुमान लगाता है, ref=<target-sha> के साथ अस्थायी ब्रांच से Full Release Validation डिस्पैच करता है, सत्यापित करता है कि प्रत्येक चाइल्ड वर्कफ़्लो headSha पिन किए गए पैरेंट वर्कफ़्लो SHA से मेल खाता है, फिर अस्थायी ब्रांच हटा देता है। नया रन बाध्य करने के लिए -f reuse_evidence=false, व्यापक परामर्शात्मक स्वीप के लिए -f release_profile=full, या वर्तमान origin/main से अब भी पहुँच योग्य किसी पुराने कमिट को पिन करने के लिए --workflow-sha <trusted-main-sha> दें। वर्कफ़्लो स्वयं कभी रिपॉज़िटरी रेफ़ नहीं लिखता। इससे कैंडिडेट में टूलिंग कमिट जोड़े बिना केवल-main रिलीज़ टूलिंग उपलब्ध रहती है और गलती से किसी नए main चाइल्ड रन को प्रमाणित करने से बचाव होता है। Code SHA के सफल होने के बाद, केवल CHANGELOG.md कमिट करें और Release SHA के साथ वही सहायक चलाएँ:

pnpm ci:full-release \
  --sha <release-sha> \
  --target-ref release/YYYY.M.PATCH

दूसरा पैरेंट उत्पाद प्रमाण का पुनः उपयोग केवल तभी करता है जब GitHub साबित करता है कि Release SHA, Code SHA से बना है और बदले हुए पथों का संपूर्ण सेट ठीक CHANGELOG.md है। यह changelog-only-release-v1 रिकॉर्ड करता है और कोई उत्पाद चाइल्ड डिस्पैच नहीं करता। npm प्रीफ़्लाइट और पैकेज/इंस्टॉल स्वीकृति अब भी Release SHA पर चलते हैं, क्योंकि उसके टारबॉल बाइट बदल गए हैं। नए Code SHA के लिए, वर्कफ़्लो लक्ष्य का समाधान करता है, मैन्युअल CI डिस्पैच करता है, फिर OpenClaw Release Checks डिस्पैच करता है। सोक सक्षम होने पर OpenClaw Release Checks इंस्टॉल स्मोक, क्रॉस-OS रिलीज़ जाँच, लाइव/E2E Docker रिलीज़-पथ कवरेज, प्रामाणिक Telegram पैकेज E2E के साथ पैकेज स्वीकृति, QA Lab समतुल्यता, लाइव Matrix और लाइव Telegram को वितरित करता है। पूर्ण/सभी रन केवल तभी स्वीकार्य है जब Full Release Validation सारांश में normal_ci, plugin_prerelease और release_checks सफल दिखें, जब तक कि किसी केंद्रित पुनः रन ने जानबूझकर अलग Plugin Prerelease चाइल्ड को न छोड़ा हो। release_package_spec या npm_telegram_package_spec के साथ केंद्रित प्रकाशित-पैकेज पुनः रन के लिए ही स्वतंत्र npm-telegram चाइल्ड का उपयोग करें। अंतिम सत्यापक सारांश में प्रत्येक चाइल्ड रन के लिए सबसे धीमे जॉब की तालिकाएँ शामिल होती हैं, ताकि रिलीज़ प्रबंधक लॉग डाउनलोड किए बिना वर्तमान क्रिटिकल पाथ देख सके। इस रिलीज़ पथ में उत्पाद-प्रदर्शन चाइल्ड केवल-आर्टिफ़ैक्ट है। अम्ब्रेला इसे publish_reports=false के साथ डिस्पैच करता है, और सत्यापन तब तक अस्वीकार होता है जब तक इसकी केवल-आर्टिफ़ैक्ट सुरक्षा-जाँच यह साबित न करे कि Clawgrit रिपोर्ट प्रकाशक स्किप रहा। संपूर्ण चरण मैट्रिक्स, सटीक वर्कफ़्लो जॉब नामों, स्थिर बनाम पूर्ण प्रोफ़ाइल के अंतर, आर्टिफ़ैक्ट और केंद्रित पुनः रन हैंडल के लिए पूर्ण रिलीज़ सत्यापन देखें। चाइल्ड वर्कफ़्लो उस SHA-पिन किए गए विश्वसनीय रेफ़ से डिस्पैच किए जाते हैं जो Full Release Validation चलाता है। प्रत्येक चाइल्ड रन को सटीक पैरेंट वर्कफ़्लो SHA का उपयोग करना अनिवार्य है। रिलीज़ प्रमाण के लिए कच्चे --ref main -f ref=<sha> डिस्पैच का उपयोग न करें; pnpm ci:full-release --sha <target-sha> --target-ref release/YYYY.M.PATCH का उपयोग करें। लाइव/प्रदाता विस्तार चुनने के लिए release_profile का उपयोग करें:

beta: सबसे तेज़ रिलीज़-महत्वपूर्ण OpenAI/कोर लाइव और Docker पथ
stable: रिलीज़ अनुमोदन के लिए बीटा के साथ स्थिर प्रदाता/बैकएंड कवरेज
full: स्थिर के साथ व्यापक परामर्शात्मक प्रदाता/मीडिया कवरेज

स्थिर और पूर्ण सत्यापन प्रमोशन से पहले हमेशा संपूर्ण लाइव/E2E, Docker रिलीज़-पथ और सीमित प्रकाशित अपग्रेड-सर्वाइवर स्वीप चलाते हैं। बीटा के लिए उसी स्वीप का अनुरोध करने हेतु run_release_soak=true का उपयोग करें। यह स्वीप नवीनतम चार स्थिर पैकेजों के साथ पिन किए गए 2026.4.23 और 2026.5.2 बेसलाइन तथा पुराने 2026.4.15 कवरेज को शामिल करता है; डुप्लिकेट बेसलाइन हटा दिए जाते हैं और प्रत्येक बेसलाइन को उसके अपने Docker रनर जॉब में शार्ड किया जाता है। सोक चलने पर OpenClaw Release Checks लक्ष्य रेफ़ को एक बार release-package-under-test के रूप में समाधान करने के लिए विश्वसनीय वर्कफ़्लो रेफ़ का उपयोग करता है और उस आर्टिफ़ैक्ट का क्रॉस-OS, पैकेज स्वीकृति तथा रिलीज़-पथ Docker जाँच में पुनः उपयोग करता है। इससे पैकेज-संबंधी सभी बॉक्स समान बाइट पर रहते हैं और बार-बार पैकेज बिल्ड से बचते हैं। बीटा के npm पर पहले से उपलब्ध होने के बाद, release_package_spec=openclaw@YYYY.M.PATCH-beta.N सेट करें ताकि रिलीज़ जाँच शिप किया गया पैकेज एक बार डाउनलोड करे, dist/build-info.json से उसका बिल्ड स्रोत SHA निकाले और उस आर्टिफ़ैक्ट का क्रॉस-OS, पैकेज स्वीकृति, रिलीज़-पथ Docker तथा पैकेज Telegram लेन में पुनः उपयोग करे। रिपॉज़िटरी/संगठन वेरिएबल सेट होने पर क्रॉस-OS OpenAI इंस्टॉल स्मोक OPENCLAW_CROSS_OS_OPENAI_MODEL का उपयोग करता है, अन्यथा openai/gpt-5.6-luna का, क्योंकि यह लेन सबसे सक्षम मॉडल का बेंचमार्क करने के बजाय पैकेज इंस्टॉल, ऑनबोर्डिंग, Gateway स्टार्टअप और एक लाइव एजेंट टर्न को प्रमाणित कर रही है। व्यापक लाइव प्रदाता मैट्रिक्स मॉडल-विशिष्ट कवरेज का स्थान बना रहता है। रिलीज़ चरण के आधार पर इन प्रकारों का उपयोग करें:

# उत्पाद-पूर्ण Code SHA को सत्यापित करें।
pnpm ci:full-release \
  --sha <code-sha> \
  --target-ref release/YYYY.M.PATCH

# Code SHA उत्पाद साक्ष्य का पुनः उपयोग करके केवल-चेंजलॉग Release SHA को सत्यापित करें।
pnpm ci:full-release \
  --sha <release-sha> \
  --target-ref release/YYYY.M.PATCH

# बीटा प्रकाशित करने के बाद, प्रकाशित-पैकेज Telegram E2E जोड़ें।
pnpm ci:full-release \
  --sha <release-sha> \
  --target-ref release/YYYY.M.PATCH \
  -f release_package_spec=openclaw@YYYY.M.PATCH-beta.N \
  -f evidence_package_spec=openclaw@YYYY.M.PATCH-beta.N \
  -f npm_telegram_provider_mode=mock-openai

केंद्रित सुधार के बाद पहले पुनः रन के रूप में पूर्ण अम्ब्रेला का उपयोग न करें। यदि एक बॉक्स विफल होता है, तो अगले प्रमाण के लिए विफल चाइल्ड वर्कफ़्लो, जॉब, Docker लेन, पैकेज प्रोफ़ाइल, मॉडल प्रदाता या QA लेन का उपयोग करें। पूर्ण अम्ब्रेला को केवल तभी दोबारा चलाएँ जब सुधार ने साझा रिलीज़ ऑर्केस्ट्रेशन बदला हो या पहले के सभी-बॉक्स साक्ष्य को अप्रचलित कर दिया हो। अम्ब्रेला का अंतिम सत्यापनकर्ता दर्ज किए गए चाइल्ड वर्कफ़्लो रन आईडी की फिर से जाँच करता है, इसलिए किसी चाइल्ड वर्कफ़्लो के सफलतापूर्वक दोबारा चलने के बाद केवल विफल Verify full validation पैरेंट जॉब को दोबारा चलाएँ। जब रिलीज़ प्रोफ़ाइल, प्रभावी सोक सेटिंग और सत्यापन इनपुट मेल खाते हों तथा या तो लक्ष्य SHA समान हो या नया लक्ष्य ऐसा वंशज हो जिसका संपूर्ण परिवर्तित पथ सेट ठीक CHANGELOG.md हो, तब rerun_group=all किसी पूर्व सफल अम्ब्रेला रन का पुनः उपयोग कर सकता है। सटीक-लक्ष्य पुनः उपयोग exact-target-full-validation-v1 दर्ज करता है; सत्यापन-पश्चात Release SHA changelog-only-release-v1 दर्ज करता है। बाद वाला केवल उत्पाद सत्यापन का पुनः उपयोग करता है। Npm प्रीफ़्लाइट, पैकेज बाइट्स, रिलीज़-नोट उद्गम और इंस्टॉल/अपडेट स्वीकृति को फिर भी Release SHA के विरुद्ध चलना आवश्यक है। संस्करण, स्रोत, जनरेट की गई सामग्री, निर्भरता, पैकेज या वर्कफ़्लो-स्वामित्व वाले लक्ष्य में किसी भी बदलाव के लिए नया Code SHA और नया पूर्ण सत्यापन आवश्यक है। समान release/* रेफ़ और पुनः रन समूह के नए अम्ब्रेला रन, प्रगति पर चल रहे रन को स्वतः प्रतिस्थापित कर देते हैं। नया पूर्ण रन बाध्य करने के लिए reuse_evidence=false पास करें। सीमित पुनर्प्राप्ति के लिए अम्ब्रेला को rerun_group पास करें। all वास्तविक रिलीज़-कैंडिडेट रन है, ci केवल सामान्य CI चाइल्ड चलाता है, plugin-prerelease केवल रिलीज़-विशिष्ट Plugin चाइल्ड चलाता है, release-checks प्रत्येक रिलीज़ बॉक्स चलाता है, और अधिक संकीर्ण रिलीज़ समूह install-smoke, cross-os, live-e2e, package, qa, qa-parity, qa-live, और npm-telegram हैं। केंद्रित npm-telegram पुनः रन के लिए release_package_spec या npm_telegram_package_spec आवश्यक है; पूर्ण/सभी रन Package Acceptance के भीतर प्रामाणिक पैकेज Telegram E2E का उपयोग करते हैं। केंद्रित क्रॉस-OS पुनः रन में cross_os_suite_filter=windows/packaged-upgrade या कोई अन्य OS/सुइट फ़िल्टर जोड़ा जा सकता है। QA रिलीज़-जाँच विफलताएँ सामान्य रिलीज़ सत्यापन को अवरुद्ध करती हैं, जिसमें कोर रनटाइम-पेयर लेन में OpenClaw डायनेमिक टूल ड्रिफ़्ट भी शामिल है। Tideclaw अल्फ़ा रन गैर-पैकेज-सुरक्षा रिलीज़-जाँच लेन को अब भी परामर्शात्मक मान सकते हैं। release_profile=beta के साथ, Run repo/live E2E validation लाइव-प्रदाता सुइट परामर्शात्मक हैं (चेतावनियाँ, अवरोधक नहीं); स्थिर और पूर्ण प्रोफ़ाइल उन्हें अवरोधक बनाए रखते हैं। जब live_suite_filter स्पष्ट रूप से Discord, WhatsApp या Slack जैसी गेटेड QA लाइव लेन का अनुरोध करता है, तब संबंधित OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED रेपो वेरिएबल सक्षम होना आवश्यक है; अन्यथा लेन को चुपचाप छोड़ने के बजाय इनपुट कैप्चर विफल हो जाता है।

Vitest

Vitest बॉक्स मैन्युअल CI चाइल्ड वर्कफ़्लो है। मैन्युअल CI जानबूझकर परिवर्तित स्कोपिंग को बायपास करता है और रिलीज़ कैंडिडेट के लिए सामान्य परीक्षण ग्राफ़ बाध्य करता है: Linux Node शार्ड, बंडल किए गए Plugin शार्ड, Plugin और चैनल अनुबंध शार्ड, Node 22 संगतता, check-*, check-additional-*, निर्मित-आर्टिफ़ैक्ट स्मोक जाँच, दस्तावेज़ जाँच, Python Skills, Windows, macOS और Control UI i18n। जब Full Release Validation बॉक्स चलाता है तब Android शामिल होता है, क्योंकि अम्ब्रेला include_android=true पास करता है; स्वतंत्र मैन्युअल CI में Android कवरेज के लिए include_android=true आवश्यक है। “क्या स्रोत ट्री ने पूर्ण सामान्य परीक्षण सुइट पास किया?” का उत्तर देने के लिए इस बॉक्स का उपयोग करें। यह रिलीज़-पथ उत्पाद सत्यापन के समान नहीं है। सुरक्षित रखने योग्य साक्ष्य:

Full Release Validation सारांश, जो डिस्पैच किए गए CI रन का URL दिखाता है
सटीक लक्ष्य SHA पर सफल CI रन
रिग्रेशन की जाँच करते समय CI जॉब से विफल या धीमे शार्ड के नाम
जब किसी रन के प्रदर्शन विश्लेषण की आवश्यकता हो, तब .artifacts/vitest-shard-timings.json जैसे Vitest टाइमिंग आर्टिफ़ैक्ट

मैन्युअल CI को सीधे केवल तभी चलाएँ जब रिलीज़ को नियतात्मक सामान्य CI की आवश्यकता हो, लेकिन Docker, QA Lab, लाइव, क्रॉस-OS या पैकेज बॉक्स की नहीं। गैर-Android प्रत्यक्ष CI के लिए पहली कमांड का उपयोग करें। जब प्रत्यक्ष रिलीज़-कैंडिडेट CI में Android शामिल करना आवश्यक हो, तब include_android=true जोड़ें:

gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.PATCH
gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.PATCH -f include_android=true

Docker

Docker बॉक्स OpenClaw Release Checks से openclaw-live-and-e2e-checks-reusable.yml तक, साथ ही रिलीज़-मोड install-smoke वर्कफ़्लो में स्थित है। यह केवल स्रोत-स्तरीय परीक्षणों के बजाय पैकेज किए गए Docker परिवेशों के माध्यम से रिलीज़ कैंडिडेट को सत्यापित करता है। रिलीज़ Docker कवरेज में शामिल हैं:

धीमे Bun ग्लोबल इंस्टॉल स्मोक को सक्षम करके पूर्ण इंस्टॉल स्मोक
लक्ष्य SHA के अनुसार रूट Dockerfile स्मोक इमेज की तैयारी/पुनः उपयोग, जिसमें QR, रूट/Gateway और इंस्टॉलर/Bun स्मोक जॉब अलग-अलग इंस्टॉल-स्मोक शार्ड के रूप में चलते हैं
रिपॉज़िटरी E2E लेन
रिलीज़-पथ Docker खंड: core, package-update-openai, package-update-anthropic, package-update-core, plugins-runtime-plugins, plugins-runtime-services, plugins-runtime-install-a से plugins-runtime-install-h तक, और openwebui
अनुरोध किए जाने पर समर्पित बड़ी-डिस्क रनर पर OpenWebUI कवरेज
विभाजित बंडल किए गए Plugin इंस्टॉल/अनइंस्टॉल लेन bundled-plugin-install-uninstall-0 से bundled-plugin-install-uninstall-23 तक
जब रिलीज़ जाँच में लाइव सुइट शामिल हों, तब लाइव/E2E प्रदाता सुइट और Docker लाइव मॉडल कवरेज

दोबारा चलाने से पहले Docker आर्टिफ़ैक्ट का उपयोग करें। रिलीज़-पथ शेड्यूलर लेन लॉग, summary.json, failures.json, चरण टाइमिंग, शेड्यूलर योजना JSON और पुनः रन कमांड के साथ .artifacts/docker-tests/ अपलोड करता है। केंद्रित पुनर्प्राप्ति के लिए सभी रिलीज़ खंड दोबारा चलाने के बजाय पुनः उपयोग योग्य लाइव/E2E वर्कफ़्लो पर docker_lanes=<lane[,lane]> का उपयोग करें। जनरेट की गई पुनः रन कमांड में उपलब्ध होने पर पूर्व package_artifact_run_id और तैयार Docker इमेज इनपुट शामिल होते हैं, जिससे विफल लेन समान टारबॉल और GHCR इमेज का पुनः उपयोग कर सकती है।

QA Lab

QA Lab बॉक्स भी OpenClaw Release Checks का भाग है। यह एजेंटिक व्यवहार और चैनल-स्तरीय रिलीज़ गेट है, जो Vitest और Docker पैकेज तंत्र से अलग है। रिलीज़ QA Lab कवरेज में शामिल हैं:

एजेंटिक पैरिटी पैक का उपयोग करके OpenAI कैंडिडेट लेन की anthropic/claude-opus-4-8 बेसलाइन से तुलना करने वाली मॉक पैरिटी लेन
qa-live-shared परिवेश का उपयोग करने वाली Matrix लाइव-अडैप्टर रिलीज़ प्रोफ़ाइल
Convex CI क्रेडेंशियल लीज़ का उपयोग करने वाली लाइव Telegram QA लेन
जब रिलीज़ टेलीमेट्री को स्पष्ट स्थानीय प्रमाण चाहिए, तब pnpm qa:otel:smoke, pnpm qa:otel:collector-smoke, pnpm qa:prometheus:smoke, या pnpm qa:observability:smoke

“क्या रिलीज़ QA परिदृश्यों और लाइव चैनल प्रवाहों में सही व्यवहार करती है?” का उत्तर देने के लिए इस बॉक्स का उपयोग करें। रिलीज़ को स्वीकृत करते समय पैरिटी, Matrix और Telegram लेन के आर्टिफ़ैक्ट URL सुरक्षित रखें। पूर्ण Matrix कवरेज डिफ़ॉल्ट रिलीज़-महत्वपूर्ण लेन के बजाय मैन्युअल शार्ड किए गए QA-Lab रन के रूप में उपलब्ध रहता है।

पैकेज

पैकेज बॉक्स इंस्टॉल किए जा सकने वाले उत्पाद का गेट है। यह Package Acceptance और रिज़ॉल्वर scripts/resolve-openclaw-package-candidate.mjs द्वारा समर्थित है। रिज़ॉल्वर किसी कैंडिडेट को Docker E2E द्वारा उपयोग किए जाने वाले package-under-test टारबॉल में सामान्यीकृत करता है, पैकेज इन्वेंट्री सत्यापित करता है, पैकेज संस्करण और SHA-256 दर्ज करता है तथा वर्कफ़्लो हार्नेस रेफ़ को पैकेज स्रोत रेफ़ से अलग रखता है। समर्थित कैंडिडेट स्रोत:

source=npm: openclaw@beta, openclaw@latest, या OpenClaw का सटीक रिलीज़ संस्करण
source=ref: चयनित workflow_ref हार्नेस के साथ किसी विश्वसनीय package_ref ब्रांच, टैग या पूर्ण कमिट SHA को पैक करें
source=url: आवश्यक package_sha256 के साथ सार्वजनिक HTTPS .tgz डाउनलोड करें; URL क्रेडेंशियल, गैर-डिफ़ॉल्ट HTTPS पोर्ट, निजी/आंतरिक/विशेष-उपयोग होस्टनेम या रिज़ॉल्व किए गए पते तथा असुरक्षित रीडायरेक्ट अस्वीकार किए जाते हैं
source=trusted-url: .github/package-trusted-sources.json में नामित नीति से आवश्यक package_sha256 और trusted_source_id के साथ HTTPS .tgz डाउनलोड करें; source=url में इनपुट-स्तरीय निजी-नेटवर्क बायपास जोड़ने के बजाय अनुरक्षक-स्वामित्व वाले एंटरप्राइज़ मिरर या निजी पैकेज रिपॉज़िटरी के लिए इसका उपयोग करें
source=artifact: किसी अन्य GitHub Actions रन द्वारा अपलोड किए गए .tgz का पुनः उपयोग करें

OpenClaw Release Checks, source=artifact, तैयार रिलीज़ पैकेज आर्टिफ़ैक्ट, suite_profile=custom,

docker_lanes=doctor-switch update-channel-switch skill-install update-corrupt-plugin upgrade-survivor published-upgrade-survivor root-managed-vps-upgrade update-restart-auth plugins-offline plugin-update plugin-binding-command-escape

, telegram_mode=mock-openai के साथ Package Acceptance चलाता है। Package Acceptance समान रिज़ॉल्व किए गए टारबॉल के विरुद्ध माइग्रेशन, अपडेट, रूट-प्रबंधित VPS अपग्रेड, कॉन्फ़िगर किए गए प्रमाणीकरण का अपडेट-पुनरारंभ, लाइव ClawHub स्किल इंस्टॉल, पुराने Plugin निर्भरता की सफ़ाई, ऑफ़लाइन Plugin फ़िक्स्चर, Plugin अपडेट, Plugin कमांड-बाइंडिंग एस्केप हार्डनिंग और Telegram पैकेज QA बनाए रखता है। अवरोधक रिलीज़ जाँच डिफ़ॉल्ट रूप से नवीनतम प्रकाशित पैकेज बेसलाइन का उपयोग करती हैं; run_release_soak=true, release_profile=stable, या release_profile=full वाली बीटा प्रोफ़ाइल, प्रकाशित-अपग्रेड-सर्वाइवर स्वीप को last-stable-4 के साथ पिन की गई 2026.4.23, 2026.5.2, और 2026.4.15 बेसलाइन तथा reported-issues परिदृश्यों तक विस्तारित करती है। पहले से जारी कैंडिडेट के लिए source=npm, प्रकाशन से पहले SHA-समर्थित स्थानीय npm टारबॉल के लिए source=ref, अनुरक्षक-स्वामित्व वाले एंटरप्राइज़/निजी मिरर के लिए source=trusted-url, या किसी अन्य GitHub Actions रन द्वारा अपलोड किए गए तैयार टारबॉल के लिए source=artifact के साथ Package Acceptance का उपयोग करें। यह अधिकांश पैकेज/अपडेट कवरेज का GitHub-मूल प्रतिस्थापन है, जिसके लिए पहले Parallels आवश्यक था। OS-विशिष्ट ऑनबोर्डिंग, इंस्टॉलर और प्लेटफ़ॉर्म व्यवहार के लिए क्रॉस-OS रिलीज़ जाँच अब भी महत्वपूर्ण हैं, लेकिन पैकेज/अपडेट उत्पाद सत्यापन में Package Acceptance को प्राथमिकता दी जानी चाहिए। अपडेट और Plugin सत्यापन की प्रामाणिक जाँच-सूची अपडेट और Plugin का परीक्षण है। किसी Plugin इंस्टॉल/अपडेट, doctor सफ़ाई या प्रकाशित-पैकेज माइग्रेशन बदलाव को कौन-सी स्थानीय, Docker, Package Acceptance या रिलीज़-जाँच लेन प्रमाणित करती है, यह तय करते समय इसका उपयोग करें। प्रत्येक स्थिर 2026.4.23+ पैकेज से संपूर्ण प्रकाशित अपडेट माइग्रेशन एक अलग मैन्युअल Update Migration वर्कफ़्लो है, Full Release CI का भाग नहीं। लेगेसी पैकेज-स्वीकृति उदारता जानबूझकर समय-सीमित है। 2026.4.25 तक के पैकेज npm पर पहले से प्रकाशित मेटाडेटा अंतराल के लिए संगतता पथ का उपयोग कर सकते हैं: टारबॉल से अनुपस्थित निजी QA इन्वेंट्री प्रविष्टियाँ, अनुपस्थित gateway install --wrapper, टारबॉल-व्युत्पन्न git फ़िक्स्चर में अनुपस्थित पैच फ़ाइलें, अनुपस्थित स्थायी update.channel, लेगेसी Plugin इंस्टॉल-रिकॉर्ड स्थान, अनुपस्थित मार्केटप्लेस इंस्टॉल-रिकॉर्ड स्थायित्व और plugins update के दौरान कॉन्फ़िगरेशन मेटाडेटा माइग्रेशन। प्रकाशित 2026.4.26 पैकेज पहले से जारी स्थानीय बिल्ड मेटाडेटा स्टैम्प फ़ाइलों के लिए चेतावनी दे सकता है। बाद के पैकेज को आधुनिक पैकेज अनुबंधों का पालन करना आवश्यक है; वही अंतराल रिलीज़ सत्यापन को विफल कर देते हैं। जब रिलीज़ का प्रश्न किसी वास्तविक इंस्टॉल किए जा सकने वाले पैकेज से संबंधित हो, तब व्यापक Package Acceptance प्रोफ़ाइल का उपयोग करें:

gh workflow run package-acceptance.yml \
  --ref main \
  -f workflow_ref=main \
  -f source=npm \
  -f package_spec=openclaw@beta \
  -f suite_profile=product \
  -f published_upgrade_survivor_baseline=openclaw@2026.4.26

सामान्य पैकेज प्रोफ़ाइल:

smoke: त्वरित पैकेज इंस्टॉल/चैनल/एजेंट, Gateway नेटवर्क और कॉन्फ़िग रीलोड लेन
package: इंस्टॉल/अपडेट/रीस्टार्ट/Plugin पैकेज अनुबंध और लाइव ClawHub स्किल इंस्टॉल प्रमाण; यह रिलीज़-जाँच का डिफ़ॉल्ट है
product: package के साथ MCP चैनल, cron/सबएजेंट क्लीनअप, OpenAI वेब खोज और OpenWebUI
full: OpenWebUI सहित Docker रिलीज़-पथ खंड
custom: केंद्रित पुनः-रन के लिए सटीक docker_lanes सूची

पैकेज-कैंडिडेट Telegram प्रमाण के लिए, Package Acceptance पर telegram_mode=mock-openai या telegram_mode=live-frontier सक्षम करें। वर्कफ़्लो समाधान किए गए package-under-test टारबॉल को Telegram लेन में भेजता है; स्वतंत्र Telegram वर्कफ़्लो प्रकाशन-पश्चात जाँचों के लिए अब भी प्रकाशित npm स्पेक स्वीकार करता है।

नियमित रिलीज़ प्रकाशन स्वचालन

बीटा, latest, Plugin, GitHub Release और प्लेटफ़ॉर्म प्रकाशन के लिए, OpenClaw Release Publish सामान्य परिवर्तनकारी प्रवेश-बिंदु है। मासिक .33+ Gateway एक्सटेंडेड-स्टेबल पथ इस ऑर्केस्ट्रेटर का उपयोग नहीं करता। नियमित वर्कफ़्लो ट्रस्टेड-पब्लिशर वर्कफ़्लो को रिलीज़ की आवश्यकतानुसार इस क्रम में ऑर्केस्ट्रेट करता है:

रिलीज़ टैग चेक आउट करें और उसका कमिट SHA समाधान करें।
सत्यापित करें कि टैग main या release/* (या अल्फ़ा प्रीरिलीज़ के लिए Tideclaw अल्फ़ा ब्रांच) से पहुँच योग्य है।
pnpm plugins:sync:check चलाएँ।
publish_scope=all-publishable और ref=<release-sha> के साथ Plugin NPM Release डिस्पैच करें।
समान स्कोप और SHA के साथ Plugin ClawHub Release डिस्पैच करें।
सहेजे गए full_release_validation_run_id और सटीक रन प्रयास को सत्यापित करने के बाद रिलीज़ टैग, npm dist-tag और सहेजे गए preflight_run_id के साथ OpenClaw NPM Release डिस्पैच करें।
स्टेबल रिलीज़ के लिए, GitHub रिलीज़ को ड्राफ़्ट के रूप में बनाएँ या अपडेट करें, स्पष्ट windows_node_tag और कैंडिडेट-अनुमोदित windows_node_installer_digests के साथ Windows Node Release डिस्पैच करें और कैनॉनिकल Windows इंस्टॉलर/चेकसम एसेट सत्यापित करें। साथ ही सटीक-टैग वाला हस्ताक्षरित APK, चेकसम और प्रोवेनेंस बनाने के लिए Android Release डिस्पैच करें। ड्राफ़्ट प्रकाशित करने से पहले दोनों नेटिव एसेट अनुबंध सत्यापित करें।

बीटा प्रकाशन उदाहरण:

gh workflow run openclaw-release-publish.yml \
  --ref main \
  -f tag=vYYYY.M.PATCH-beta.N \
  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \
  -f full_release_validation_run_id=<successful-full-release-validation-run-id> \
  -f full_release_validation_run_attempt=<successful-full-release-validation-run-attempt> \
  -f npm_dist_tag=beta

डिफ़ॉल्ट बीटा dist-tag पर स्टेबल प्रकाशन:

gh workflow run openclaw-release-publish.yml \
  --ref main \
  -f tag=vYYYY.M.PATCH \
  -f windows_node_tag=vX.Y.Z \
  -f windows_node_installer_digests='{"OpenClawCompanion-Setup-x64.exe":"sha256:<approved-x64-sha256>","OpenClawCompanion-Setup-arm64.exe":"sha256:<approved-arm64-sha256>"}' \
  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \
  -f full_release_validation_run_id=<successful-full-release-validation-run-id> \
  -f full_release_validation_run_attempt=<successful-full-release-validation-run-attempt> \
  -f npm_dist_tag=beta

सीधे latest पर स्टेबल प्रोमोशन स्पष्ट है:

gh workflow run openclaw-release-publish.yml \
  --ref main \
  -f tag=vYYYY.M.PATCH \
  -f windows_node_tag=vX.Y.Z \
  -f windows_node_installer_digests='{"OpenClawCompanion-Setup-x64.exe":"sha256:<approved-x64-sha256>","OpenClawCompanion-Setup-arm64.exe":"sha256:<approved-arm64-sha256>"}' \
  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \
  -f full_release_validation_run_id=<successful-full-release-validation-run-id> \
  -f full_release_validation_run_attempt=<successful-full-release-validation-run-attempt> \
  -f npm_dist_tag=latest

निचले-स्तर के Plugin NPM Release और Plugin ClawHub Release वर्कफ़्लो का उपयोग केवल केंद्रित मरम्मत या पुनः-प्रकाशन कार्य के लिए करें। जब publish_openclaw_npm=true हो, तब OpenClaw Release Publish, plugin_publish_scope=selected को अस्वीकार करता है, ताकि मुख्य पैकेज @openclaw/diffs-language-pack सहित प्रत्येक प्रकाशन-योग्य आधिकारिक Plugin के बिना शिप न हो सके। चुने गए Plugin की मरम्मत के लिए, plugin_publish_scope=selected और plugins=@openclaw/name के साथ publish_openclaw_npm=false सेट करें या चाइल्ड वर्कफ़्लो को सीधे डिस्पैच करें। पहली बार प्रकाशन वाला ClawHub बूटस्ट्रैप अपवाद है: विश्वसनीय main से Plugin ClawHub New डिस्पैच करें और पूर्ण लक्षित रिलीज़ SHA को ref के माध्यम से पास करें। बूटस्ट्रैप वर्कफ़्लो को कभी भी रिलीज़ टैग या ब्रांच से स्वयं न चलाएँ:

gh workflow run plugin-clawhub-new.yml \
  --ref main \
  -f plugins=@openclaw/name \
  -f ref=<full-40-character-release-sha> \
  -f pretag_validation=true \
  -f dry_run=true

प्री-टैग सत्यापन के लिए dry_run=true आवश्यक है, यह रिलीज़-टैग और पैरेंट-रन इनपुट अस्वीकार करता है और केवल main या release/* से पहुँच योग्य सटीक लक्ष्य स्वीकार करता है। यह ClawHub क्रेडेंशियल लोड नहीं करता, पैकेज बाइट प्रकाशित नहीं करता या ट्रस्टेड पब्लिशर कॉन्फ़िगरेशन नहीं बदलता। वर्कफ़्लो फिर भी लाइव रजिस्ट्री योजना समाधान करता है, केवल सीक्रेट-रहित जॉब में लक्ष्य को चेक आउट और पैक करता है, लॉक किया गया ClawHub टूलचेन तैयार करता है और रिलीज़ टैग के अस्तित्व में आने से पहले अपरिवर्तनीय आर्टिफ़ैक्ट तथा पैकेज स्लग/पहचान सत्यापित करता है। सीक्रेट-रहित पैक जॉब समाप्त होने के बाद ही clawhub-plugin-bootstrap एनवायरनमेंट अनुमोदित करें; इस संरक्षित सत्यापन जॉब में कोई क्रेडेंशियल या परिवर्तन कमांड नहीं है। टैगिंग के बाद अनुमोदित ड्राई रन या वास्तविक बूटस्ट्रैप में सटीक रिलीज़ टैग के साथ पैरेंट OpenClaw Release Publish रन आईडी, प्रयास और ब्रांच शामिल होने चाहिए। पैरेंट अपने स्वयं के वर्कफ़्लो SHA और Plugin ClawHub New के लिए एक अलग सटीक विश्वसनीय main SHA को प्रमाणित करता है; चाइल्ड रन और प्रत्येक संरक्षित एनवायरनमेंट अनुमोदन को उस अनुमोदित चाइल्ड SHA से मेल खाना चाहिए। प्रत्येक प्रकाशन प्रयास और ट्रस्टेड-पब्लिशर परिवर्तन से पहले रिलीज़ टैग की पुनः जाँच की जाती है। पैक जॉब एक अपरिवर्तनीय आर्टिफ़ैक्ट अपलोड करता है, जिसका नाम, Actions आर्टिफ़ैक्ट आईडी/डाइजेस्ट, निर्माता रन/प्रयास, लक्ष्य SHA और प्रत्येक पैकेज का टारबॉल SHA-256/आकार सत्यापन और संरक्षित जॉब में आगे पहुँचाया जाता है। संरक्षित जॉब केवल विश्वसनीय main टूलिंग चेक आउट करता है, GitHub API के माध्यम से आर्टिफ़ैक्ट ट्यूपल सत्यापित करता है, सटीक आर्टिफ़ैक्ट आईडी से डाउनलोड करता है, प्रत्येक टारबॉल को पुनः हैश करता है और पिन किए गए CLI के USTAR कैनॉनिकलाइज़ेशन नियमों के अनुसार स्थानीय TAR पथ तथा पैकेज पहचान सत्यापित करता है। इसके बाद प्रत्येक कैंडिडेट पिन किए गए CLI के प्रकाशन ड्राई-रन से गुजरता है, जो रजिस्ट्री लुकअप या प्रमाणीकरण से पहले लौट आता है। क्रेडेंशियल-जॉब प्रीफ़िल्टर संपीड़ित ClawPacks को 120 MiB, कुल फ़ाइल पेलोड को 50 MiB, विस्तारित TAR डेटा को 64 MiB और TAR प्रविष्टि संख्या को 10,000 तक सीमित करता है। मौजूदा-पैकेज ट्रस्टेड-पब्लिशर मरम्मत केवल कॉन्फ़िगर तक सीमित रहती है, लेकिन ट्रस्टेड-पब्लिशर कॉन्फ़िगरेशन बदलने से पहले यह फिर भी लक्ष्य को पैक करती है और अनुरोधित टैग के साथ सटीक रजिस्ट्री बाइट तथा मेटाडेटा समानता अनिवार्य करती है। प्रकाशन-पश्चात सत्यापन ClawHub आर्टिफ़ैक्ट डाउनलोड करता है और समान SHA-256 तथा आकार आवश्यक करता है। विफल जॉब का पुनः-रन रिकवरी किसी पिछले प्रयास के पैकेज आर्टिफ़ैक्ट का पुनः उपयोग केवल तभी कर सकती है, जब सटीक निर्माता जॉब सफलतापूर्वक पूरा हुआ हो। अंतिम प्रमाण लॉक किए गए ClawHub संस्करण, लॉक SHA-256 और npm इंटीग्रिटी को भी बाँधता है। बेमेल होने पर नया पैकेज संस्करण आवश्यक है।

NPM वर्कफ़्लो इनपुट

OpenClaw NPM Release ये ऑपरेटर-नियंत्रित इनपुट स्वीकार करता है:

tag: आवश्यक रिलीज़ टैग, जैसे v2026.4.2, v2026.4.2-1, v2026.4.2-beta.1 या v2026.4.2-alpha.1; जब preflight_only=true हो, तो यह केवल-सत्यापन प्रीफ़्लाइट के लिए वर्तमान पूर्ण 40-वर्ण वाला वर्कफ़्लो-ब्रांच कमिट SHA भी हो सकता है
preflight_only: केवल सत्यापन/बिल्ड/पैकेज के लिए true, वास्तविक प्रकाशन पथ के लिए false
preflight_run_id: मौजूदा सफल प्रीफ़्लाइट रन आईडी, वास्तविक प्रकाशन पथ पर आवश्यक, ताकि वर्कफ़्लो तैयार टारबॉल को दोबारा बनाने के बजाय पुनः उपयोग करे
full_release_validation_run_id: इस टैग/SHA के लिए सफल Full Release Validation रन आईडी, वास्तविक प्रकाशन के लिए आवश्यक। बीटा प्रकाशन चेतावनी के साथ केवल प्रीफ़्लाइट पर आगे बढ़ सकते हैं, लेकिन स्टेबल/latest प्रोमोशन के लिए यह अब भी आवश्यक है।
full_release_validation_run_attempt: full_release_validation_run_id के साथ युग्मित सटीक सकारात्मक रन प्रयास; रन आईडी दिए जाने पर हमेशा आवश्यक, ताकि पुनः-रन प्रकाशन के दौरान प्राधिकरण प्रमाण न बदल सकें।
release_publish_run_id: अनुमोदित OpenClaw Release Publish रन आईडी; जब यह वर्कफ़्लो उस पैरेंट द्वारा डिस्पैच किया जाता है, तब आवश्यक (बॉट-एक्टर वास्तविक-प्रकाशन कॉल)
plugin_npm_run_id: सफल सटीक-हेड Plugin NPM Release रन आईडी; वास्तविक extended-stable कोर प्रकाशन के लिए आवश्यक
npm_dist_tag: प्रकाशन पथ के लिए npm लक्ष्य टैग; alpha, beta, latest या extended-stable स्वीकार करता है और डिफ़ॉल्ट beta है। अंतिम पैच 33 और उसके बाद के संस्करणों को extended-stable का उपयोग करना आवश्यक है; डिफ़ॉल्ट रूप से, extended-stable पहले के पैच अस्वीकार करता है और यह गैर-अंतिम टैग हमेशा अस्वीकार करता है।
bypass_extended_stable_guard: केवल-परीक्षण बूलियन, डिफ़ॉल्ट false; npm_dist_tag=extended-stable के साथ रिलीज़ पहचान, आर्टिफ़ैक्ट, अनुमोदन और रीडबैक जाँच सुरक्षित रखते हुए मासिक एक्सटेंडेड-स्टेबल पात्रता को बायपास करता है।

Plugin NPM Release मौजूदा रिलीज़ व्यवहार के लिए npm_dist_tag=default या संरक्षित मासिक पथ के लिए npm_dist_tag=extended-stable स्वीकार करता है। एक्सटेंडेड-स्टेबल विकल्प के लिए publish_scope=all-publishable, खाली plugins इनपुट, 33 या उससे ऊपर का अंतिम पैच और अपने सटीक शीर्ष पर कैनॉनिकल extended-stable/YYYY.M.33 ब्रांच आवश्यक है। यह Plugin latest या beta को कभी नहीं बदलता। नए पैकेज संस्करण OIDC ट्रस्टेड प्रकाशन (npm publish --tag extended-stable) के माध्यम से परमाण्विक रूप से extended-stable प्राप्त करते हैं; यह स्रोत वर्कफ़्लो टोकन-प्रमाणित npm dist-tag add का उपयोग नहीं करता। पुनः प्रयास npm में पहले से मौजूद सटीक संस्करणों को छोड़ देते हैं, फिर तब तक सुरक्षित रूप से विफल रहते हैं जब तक पूर्ण रीडबैक पुष्टि न कर दे कि प्रत्येक सटीक पैकेज और extended-stable टैग अभिसरित हो गए हैं। OpenClaw Release Publish ये ऑपरेटर-नियंत्रित इनपुट स्वीकार करता है:

tag: आवश्यक रिलीज़ टैग; पहले से मौजूद होना चाहिए
preflight_run_id: सफल OpenClaw NPM Release प्रीफ़्लाइट रन आईडी; publish_openclaw_npm=true या plugin_publish_scope=all-publishable होने पर आवश्यक
full_release_validation_run_id: सफल Full Release Validation रन आईडी; publish_openclaw_npm=true या plugin_publish_scope=all-publishable होने पर आवश्यक
full_release_validation_run_attempt: full_release_validation_run_id के साथ युग्मित सटीक सकारात्मक प्रयास; रन आईडी दिए जाने पर हमेशा आवश्यक
windows_node_tag: सटीक गैर-प्रीरिलीज़ openclaw/openclaw-windows-node रिलीज़ टैग; स्टेबल OpenClaw प्रकाशन के लिए आवश्यक
windows_node_installer_digests: मौजूदा Windows इंस्टॉलर नामों से उनके पिन किए गए sha256: डाइजेस्ट तक कैंडिडेट-अनुमोदित संक्षिप्त JSON मैप; स्टेबल OpenClaw प्रकाशन के लिए आवश्यक
npm_telegram_run_id: अंतिम रिलीज़ प्रमाण में शामिल करने के लिए वैकल्पिक सफल NPM Telegram Beta E2E रन आईडी
npm_dist_tag: OpenClaw पैकेज के लिए npm लक्ष्य टैग, alpha, beta या latest में से एक
plugin_publish_scope: डिफ़ॉल्ट all-publishable; publish_openclaw_npm=false के साथ केवल केंद्रित Plugin-मरम्मत कार्य के लिए selected का उपयोग करें
plugins: plugin_publish_scope=selected होने पर कॉमा से अलग किए गए @openclaw/* पैकेज नाम
publish_openclaw_npm: डिफ़ॉल्ट true; वर्कफ़्लो को केवल-Plugin मरम्मत ऑर्केस्ट्रेटर के रूप में उपयोग करते समय ही false सेट करें
release_profile: रिलीज़ प्रमाण सारांशों के लिए उपयोग की जाने वाली रिलीज़ कवरेज प्रोफ़ाइल; डिफ़ॉल्ट from-validation, जो इसे सत्यापन मैनिफ़ेस्ट से पढ़ता है, या beta, stable अथवा full से ओवरराइड करें
wait_for_clawhub: डिफ़ॉल्ट false, ताकि npm उपलब्धता ClawHub साइडकार से अवरुद्ध न हो; true केवल तब सेट करें, जब वर्कफ़्लो पूर्णता में ClawHub पूर्णता शामिल होना आवश्यक हो

OpenClaw Release Checks ये ऑपरेटर-नियंत्रित इनपुट स्वीकार करता है:

ref: सत्यापित करने के लिए ब्रांच, टैग या पूर्ण कमिट SHA। सीक्रेट वाले जाँचों के लिए आवश्यक है कि समाधान किया गया कमिट किसी OpenClaw ब्रांच या रिलीज़ टैग से पहुँच योग्य हो।
run_release_soak: बीटा रिलीज़ जाँचों के लिए व्यापक लाइव/E2E, Docker रिलीज़-पथ और सभी-पिछले संस्करणों से अपग्रेड के बाद भी कार्यशील रहने की दीर्घकालिक जाँच को सक्षम करें। इसे release_profile=stable और release_profile=full द्वारा अनिवार्य रूप से सक्षम किया जाता है।

नियम:

पैच 33 से नीचे के नियमित अंतिम और सुधार संस्करण beta या latest, दोनों में से किसी पर प्रकाशित किए जा सकते हैं। पैच 33 या उससे ऊपर के अंतिम संस्करणों को extended-stable पर ही प्रकाशित करना आवश्यक है, और उस सीमा पर सुधार-प्रत्यय वाले संस्करण अस्वीकार कर दिए जाते हैं।
बीटा पूर्व-रिलीज़ टैग केवल beta पर प्रकाशित किए जा सकते हैं; अल्फ़ा पूर्व-रिलीज़ टैग केवल alpha पर प्रकाशित किए जा सकते हैं
OpenClaw NPM Release के लिए, पूर्ण कमिट SHA इनपुट की अनुमति केवल तब है जब preflight_only=true
OpenClaw Release Checks और Full Release Validation हमेशा केवल सत्यापन के लिए हैं
वास्तविक प्रकाशन पथ में प्रीफ़्लाइट के दौरान उपयोग किए गए उसी npm_dist_tag का उपयोग होना आवश्यक है; प्रकाशन जारी रहने से पहले वर्कफ़्लो उस मेटाडेटा को सत्यापित करता है

नियमित बीटा/नवीनतम स्थिर रिलीज़ क्रम

यह पुराना क्रम उस नियमित समन्वित रिलीज़ के लिए है, जो plugins, GitHub Release, Windows और अन्य प्लेटफ़ॉर्म कार्यों का भी स्वामी है। यह इस पृष्ठ के शीर्ष पर दस्तावेज़ित मासिक .33+ Gateway विस्तारित-स्थिर पथ नहीं है। नियमित समन्वित स्थिर रिलीज़ तैयार करते समय:

OpenClaw NPM Release को preflight_only=true के साथ चलाएँ। टैग मौजूद होने से पहले, प्रीफ़्लाइट वर्कफ़्लो के केवल-सत्यापन ड्राई रन के लिए वर्तमान पूर्ण वर्कफ़्लो-ब्रांच कमिट SHA का उपयोग किया जा सकता है।
सामान्य बीटा-प्रथम प्रवाह के लिए npm_dist_tag=beta चुनें, या केवल तभी latest चुनें जब आप जानबूझकर सीधे स्थिर प्रकाशन करना चाहते हों।
जब एक मैन्युअल वर्कफ़्लो से सामान्य CI के साथ लाइव प्रॉम्प्ट कैश, Docker, QA Lab, Matrix और Telegram कवरेज चाहिए, तब रिलीज़ ब्रांच, रिलीज़ टैग या पूर्ण कमिट SHA पर Full Release Validation चलाएँ। यदि जानबूझकर केवल निर्धारक सामान्य परीक्षण ग्राफ़ चाहिए, तो इसके बजाय रिलीज़ रेफ़ पर मैन्युअल CI वर्कफ़्लो चलाएँ।
उस सटीक गैर-पूर्व-रिलीज़ openclaw/openclaw-windows-node रिलीज़ टैग को चुनें, जिसके हस्ताक्षरित x64 और ARM64 इंस्टॉलर वितरित किए जाने चाहिए। इसे windows_node_tag के रूप में सहेजें और उनके सत्यापित डाइजेस्ट मैप को windows_node_installer_digests के रूप में सहेजें। रिलीज़-कैंडिडेट सहायक दोनों को रिकॉर्ड करता है और अपने जनरेट किए गए प्रकाशन कमांड में शामिल करता है।
सफल preflight_run_id, full_release_validation_run_id और सटीक full_release_validation_run_attempt को सहेजें।
विश्वसनीय main से OpenClaw Release Publish को उसी tag, उसी npm_dist_tag, चुने गए windows_node_tag, उसके सहेजे गए windows_node_installer_digests, सहेजे गए preflight_run_id, full_release_validation_run_id और full_release_validation_run_attempt के साथ चलाएँ। यह OpenClaw npm पैकेज को प्रोमोट करने से पहले बाहरीकृत plugins को npm और ClawHub पर प्रकाशित करता है।
यदि रिलीज़ beta पर पहुँची है, तो उस स्थिर संस्करण को beta से latest पर प्रोमोट करने के लिए openclaw/releases/.github/workflows/openclaw-npm-dist-tags.yml वर्कफ़्लो का उपयोग करें।
यदि रिलीज़ जानबूझकर सीधे latest पर प्रकाशित की गई है और beta को तुरंत उसी स्थिर बिल्ड का अनुसरण करना चाहिए, तो दोनों dist-tags को स्थिर संस्करण पर इंगित करने के लिए उसी रिलीज़ वर्कफ़्लो का उपयोग करें, या उसके निर्धारित स्व-सुधार सिंक को बाद में beta स्थानांतरित करने दें।

dist-tag परिवर्तन रिलीज़ लेजर रेपो में रहता है क्योंकि इसके लिए अब भी NPM_TOKEN आवश्यक है, जबकि स्रोत रेपो प्रकाशन को केवल OIDC तक सीमित रखता है। इससे प्रत्यक्ष प्रकाशन पथ और बीटा-प्रथम प्रोमोशन पथ, दोनों दस्तावेज़ित और ऑपरेटर को दृश्यमान रहते हैं। यदि किसी मेंटेनर को स्थानीय npm प्रमाणीकरण का सहारा लेना पड़े, तो किसी भी 1Password CLI (op) कमांड को केवल एक समर्पित tmux सत्र के भीतर चलाएँ। मुख्य एजेंट शेल से सीधे op को कॉल न करें; इसे tmux के भीतर रखने से प्रॉम्प्ट, चेतावनियाँ और OTP प्रबंधन देखे जा सकते हैं तथा बार-बार आने वाली होस्ट चेतावनियाँ रोकी जाती हैं।

सार्वजनिक संदर्भ

वास्तविक रनबुक के लिए मेंटेनर openclaw/maintainers/release/README.md में निजी रिलीज़ दस्तावेज़ों का उपयोग करते हैं।

Release notes

Maturity

Release process

Testing and CI

रिलीज़ नीति

संस्करण नामकरण

रिलीज़ आवृत्ति

मासिक Gateway extended-stable प्रकाशन

उम्मीदवार तैयार और स्थिर करें

npm पैकेज प्रकाशित करें

सत्यापित करें और पुनर्प्राप्त करें

नियमित रिलीज़ ऑपरेटर चेकलिस्ट

स्थिर main समापन

रिलीज़ प्रीफ़्लाइट

रिलीज़ परीक्षण बॉक्स

Vitest

Docker

QA Lab

पैकेज

नियमित रिलीज़ प्रकाशन स्वचालन

NPM वर्कफ़्लो इनपुट

नियमित बीटा/नवीनतम स्थिर रिलीज़ क्रम

सार्वजनिक संदर्भ

संबंधित

​संस्करण नामकरण

​रिलीज़ आवृत्ति

​मासिक Gateway extended-stable प्रकाशन

​उम्मीदवार तैयार और स्थिर करें

​npm पैकेज प्रकाशित करें

​सत्यापित करें और पुनर्प्राप्त करें

​नियमित रिलीज़ ऑपरेटर चेकलिस्ट

​स्थिर main समापन

​रिलीज़ प्रीफ़्लाइट

​रिलीज़ परीक्षण बॉक्स

​Vitest

​Docker

​QA Lab

​पैकेज

​नियमित रिलीज़ प्रकाशन स्वचालन

​NPM वर्कफ़्लो इनपुट

​नियमित बीटा/नवीनतम स्थिर रिलीज़ क्रम

​सार्वजनिक संदर्भ

​संबंधित

संस्करण नामकरण

रिलीज़ आवृत्ति

मासिक Gateway extended-stable प्रकाशन

उम्मीदवार तैयार और स्थिर करें

npm पैकेज प्रकाशित करें

सत्यापित करें और पुनर्प्राप्त करें

नियमित रिलीज़ ऑपरेटर चेकलिस्ट

स्थिर main समापन

रिलीज़ प्रीफ़्लाइट

रिलीज़ परीक्षण बॉक्स

Vitest

Docker

QA Lab

पैकेज

नियमित रिलीज़ प्रकाशन स्वचालन

NPM वर्कफ़्लो इनपुट

नियमित बीटा/नवीनतम स्थिर रिलीज़ क्रम

सार्वजनिक संदर्भ

संबंधित