OpenClawDocs
View as MarkdownView this page as plain textOpen in ChatGPTAsk questions about this pageOpen in ClaudeAsk questions about this page

Release and CI

रिलीज़ नीति

OpenClaw वर्तमान में उपयोगकर्ताओं के लिए तीन अपडेट चैनल उपलब्ध कराता है:

  • stable: मौजूदा प्रवर्तित रिलीज़ चैनल, जो अलग CLI/चैनल माइलस्टोन आने तक अभी भी npm latest के माध्यम से रिज़ॉल्व होता है
  • beta: प्रीरिलीज़ टैग, जो npm beta पर प्रकाशित होते हैं
  • dev: main का बदलता हुआ नवीनतम हेड

इसके अतिरिक्त, रिलीज़ ऑपरेटर पिछले पूरे हुए महीने के मुख्य पैकेज को patch 33 से शुरू करते हुए npm extended-stable पर प्रकाशित कर सकते हैं। वर्तमान महीने की नियमित अंतिम लाइन npm latest पर जारी रहती है; ऑपरेटर-पक्ष का यह प्रकाशन विभाजन अपने-आप CLI अपडेट-चैनल रिज़ॉल्यूशन को नहीं बदलता।

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

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

  • मासिक npm 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
  • Alpha प्रीरिलीज़ संस्करण: YYYY.M.PATCH-alpha.N, git टैग vYYYY.M.PATCH-alpha.N
  • महीने या patch में आरंभिक शून्य कभी न जोड़ें
  • PATCH एक क्रमिक मासिक रिलीज़-ट्रेन संख्या है, कैलेंडर का दिन नहीं। नियमित अंतिम और beta रिलीज़ वर्तमान ट्रेन को आगे बढ़ाते हैं; केवल-alpha टैग कभी भी beta/नियमित patch संख्या का उपयोग नहीं करते या उसे आगे नहीं बढ़ाते, इसलिए beta या नियमित ट्रेन चुनते समय अधिक patch संख्या वाले पुराने केवल-alpha टैग की उपेक्षा करें।
  • Alpha/nightly बिल्ड अगली अप्रकाशित patch ट्रेन का उपयोग करते हैं और बार-बार होने वाले बिल्ड के लिए केवल alpha.N बढ़ाते हैं। उस patch का beta बन जाने के बाद, नए alpha बिल्ड अगले patch पर चले जाते हैं।
  • npm संस्करण अपरिवर्तनीय हैं: प्रकाशित टैग को कभी मिटाएँ, दोबारा प्रकाशित या पुनः उपयोग न करें। इसके बजाय अगली प्रीरिलीज़ संख्या या अगला मासिक patch जारी करें।
  • latest वर्तमान नियमित/दैनिक npm लाइन का अनुसरण करना जारी रखता है; beta वर्तमान beta इंस्टॉल लक्ष्य है
  • extended-stable का अर्थ समर्थित पिछले-महीने का npm पैकेज है, जिसकी शुरुआत patch 33 से होती है; patch 34 और उसके बाद के संस्करण उस मासिक लाइन पर रखरखाव रिलीज़ हैं
  • नियमित अंतिम और नियमित सुधार रिलीज़ डिफ़ॉल्ट रूप से npm beta पर प्रकाशित होती हैं; रिलीज़ ऑपरेटर स्पष्ट रूप से latest को लक्षित कर सकते हैं या बाद में जाँचे-परखे beta बिल्ड को प्रवर्तित कर सकते हैं
  • समर्पित मासिक extended-stable पथ मुख्य npm पैकेज और npm पर प्रकाशित किए जा सकने वाले प्रत्येक आधिकारिक Plugin को ठीक उसी संस्करण पर प्रकाशित करता है। यह Plugins को ClawHub पर प्रकाशित नहीं करता और न ही macOS या Windows आर्टिफ़ैक्ट, GitHub Release, निजी-रिपॉज़िटरी dist-tags, Docker इमेज, मोबाइल आर्टिफ़ैक्ट या वेबसाइट डाउनलोड प्रकाशित करता है।
  • प्रत्येक नियमित अंतिम रिलीज़ npm पैकेज, macOS ऐप, हस्ताक्षरित स्टैंडअलोन Android APK और हस्ताक्षरित Windows Hub इंस्टॉलर एक साथ जारी करती है। Beta रिलीज़ सामान्यतः पहले npm/package पथ को सत्यापित और प्रकाशित करती हैं; नेटिव ऐप को build/sign/notarize/promote करना नियमित अंतिम रिलीज़ के लिए आरक्षित रहता है, जब तक स्पष्ट रूप से अनुरोध न किया जाए।

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

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

केवल npm के लिए मासिक extended-stable प्रकाशन

यह नीचे दी गई नियमित रिलीज़ प्रक्रिया का एक समर्पित अपवाद है। पूरे हो चुके महीने YYYY.M के लिए extended-stable/YYYY.M.33 बनाएँ; उसी शाखा से vYYYY.M.33 और बाद के रखरखाव patch प्रकाशित करें। रिलीज़ टैग, शाखा टिप, checkout, पैकेज संस्करण, npm प्रीफ़्लाइट और Full Release Validation रन सभी को एक ही commit की पहचान करनी चाहिए। संरक्षित main में पहले से ही patch 33 से नीचे किसी स्पष्ट रूप से बाद के कैलेंडर महीने का अंतिम संस्करण होना चाहिए; main के एक महीने से अधिक आगे बढ़ जाने के बाद भी रखरखाव patch पात्र बने रहते हैं।

ठीक उसी extended-stable शाखा पर, रूट पैकेज को YYYY.M.P पर बढ़ाएँ, pnpm release:prep चलाएँ और सत्यापित करें कि प्रकाशित किए जा सकने वाले प्रत्येक extension पैकेज का संस्करण समान है। सभी जनरेट किए गए परिवर्तनों को commit और push करें, उस commit पर अपरिवर्तनीय vYYYY.M.P टैग बनाएँ और push करें तथा परिणामी पूर्ण SHA दर्ज करें। वर्कफ़्लो इस तैयार ट्री का उपयोग करते हैं; वे आपके लिए संस्करणों को बढ़ाते या सिंक्रनाइज़ नहीं करते।

ठीक उसी तैयार शाखा टिप से npm प्रीफ़्लाइट और Full Release Validation चलाएँ, फिर दोनों रन ID और सफल Full Release Validation रन प्रयास सहेजें:

bash
gh workflow run openclaw-npm-release.yml \  --ref extended-stable/YYYY.M.33 \  -f tag=vYYYY.M.P \  -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

release_profile=stable मौजूदा सत्यापन-गहराई प्रोफ़ाइल है; यह npm extended-stable dist-tag से अलग है और जानबूझकर अपरिवर्तित है।

दोनों रन सफल होने के बाद, npm पर प्रकाशित किए जा सकने वाले प्रत्येक आधिकारिक Plugin को ठीक उसी शाखा टिप से प्रकाशित करें। Patch P का 33 या उससे अधिक होना आवश्यक है। पूर्ण रिलीज़ SHA को ref के रूप में दें, संपूर्ण मैट्रिक्स और रजिस्ट्री रीडबैक की प्रतीक्षा करें, फिर सफल Plugin NPM Release रन ID सहेजें:

bash
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 पैकेज इन्वेंट्री का उपयोग करता है, जिसमें वे पैकेज भी शामिल हैं जिनका स्रोत नहीं बदला। सफल होने से पहले यह प्रत्येक सटीक पैकेज और प्रत्येक Plugin extended-stable टैग को सत्यापित करता है। यदि कोई आंशिक रन विफल हो जाता है, तो वही कमांड दोबारा चलाएँ: पहले से प्रकाशित पैकेज पुनः उपयोग किए जाते हैं, अनुपस्थित या पुराने Plugin टैग npm रिलीज़ परिवेश के अंतर्गत समन्वित किए जाते हैं और अंतिम रीडबैक फिर भी पूरे पैकेज समूह को कवर करता है।

Plugin वर्कफ़्लो सफल होने और npm रिलीज़ परिवेश तैयार होने के बाद, ठीक वही मुख्य प्रीफ़्लाइट tarball प्रकाशित करें। मुख्य प्रकाशन सत्यापित करता है कि संदर्भित Plugin रन उसी कैनोनिकल शाखा और सटीक स्रोत SHA पर completed/success है:

bash
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>

ऐसे fork या गैर-प्रोडक्शन पूर्वाभ्यास के लिए, जो जानबूझकर मासिक .33 या संरक्षित-main माह नीति को पूरा नहीं कर सकता, npm प्रीफ़्लाइट और प्रकाशन दोनों dispatch में -f bypass_extended_stable_guard=true जोड़ें। डिफ़ॉल्ट false है। बायपास केवल npm_dist_tag=extended-stable के साथ स्वीकार किया जाता है और वर्कफ़्लो सारांश में दर्ज होता है। यह कैनोनिकल extended-stable/YYYY.M.33 वर्कफ़्लो ref, branch-tip/tag/checkout समानता, अंतिम-टैग सिंटैक्स, package/tag संस्करण समानता, संदर्भित रन और manifest पहचान, tarball उत्पत्ति, परिवेश स्वीकृति, रजिस्ट्री रीडबैक या selector सुधार प्रमाण को बायपास नहीं करता।

प्रकाशन वर्कफ़्लो संदर्भित प्रीफ़्लाइट, सत्यापन और Plugin रन की पहचान, तैयार tarball digest और मुख्य रजिस्ट्री selectors को सत्यापित करता है। वर्कफ़्लो सफल होने के बाद परिणाम की स्वतंत्र रूप से पुष्टि करें:

bash
npm view [email protected] version --userconfig "$(mktemp)"npm view openclaw@extended-stable version --userconfig "$(mktemp)"

दोनों कमांड को YYYY.M.P लौटाना आवश्यक है। यदि प्रकाशन सफल हो जाता है लेकिन selector रीडबैक विफल रहता है, तो अपरिवर्तनीय पैकेज संस्करण को दोबारा प्रकाशित न करें। विफल वर्कफ़्लो के हमेशा चलने वाले सारांश में प्रिंट किए गए एकल npm dist-tag add [email protected] extended-stable सुधार कमांड का उपयोग करें, फिर दोनों स्वतंत्र रीडबैक दोहराएँ। पिछले selector पर rollback करना एक अलग ऑपरेटर निर्णय है, रीडबैक सुधार पथ नहीं।

सार्वजनिक सहायता दस्तावेज़ शुरुआत में Slack, Discord और Codex को समर्थित extended-stable Plugin सतहों के रूप में निर्दिष्ट करते हैं। वह सूची सहायता संबंधी कथन है, रिलीज़-कोड allowlist नहीं: npm पर प्रकाशित किए जा सकने वाले प्रत्येक आधिकारिक Plugin के लिए समान सटीक-संस्करण प्रकाशन पथ लागू होता है।

नीचे दी गई नियमित चेकलिस्ट beta, latest, GitHub Release, Plugins, macOS, Windows और अन्य प्लेटफ़ॉर्म प्रकाशन का स्वामित्व बनाए रखती है। केवल npm वाले इस extended-stable पथ के लिए वे चरण न चलाएँ।

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

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

  1. वर्तमान main से शुरू करें: नवीनतम बदलाव pull करें, पुष्टि करें कि लक्षित commit push किया गया है और पुष्टि करें कि main CI से शाखा बनाने के लिए पर्याप्त रूप से हरा है।

  2. उस commit से release/YYYY.M.PATCH बनाएँ। Backport वैकल्पिक हैं; केवल ऑपरेटर द्वारा चुना गया समूह लागू करें। प्रत्येक आवश्यक संस्करण स्थान को बढ़ाएँ, pnpm release:prep चलाएँ, रिलीज़ सुधार और आवश्यक forward-port पूरे करें तथा src/plugins/compat/registry.ts के साथ src/commands/doctor/shared/deprecation-compat.ts की समीक्षा करें।

  3. चेंजलॉग से पहले के उत्पाद-पूर्ण commit को Code SHA के रूप में फ़्रीज़ करें। निर्धारक स्रोत प्रीफ़्लाइट चलाएँ, फिर node scripts/full-release-validation-at-sha.mjs --sha <code-sha> --target-ref release/YYYY.M.PATCH का उपयोग करें। इससे विश्वसनीय वर्कफ़्लो टूलिंग पिन होती है, जबकि संपूर्ण Vitest, Docker, QA, पैकेज और प्रदर्शन मैट्रिक्स सटीक Code SHA को लक्षित करते हैं।

  4. संपादन से पहले विफलताओं का वर्गीकरण करें। उत्पाद/कोड विफलता नया Code SHA बनाती है और उस SHA के लिए सफल पूर्ण सत्यापन आवश्यक करती है। वर्कफ़्लो, harness, credential, approval या infrastructure विफलता को उसकी स्वामी सतह में सुधारा जाता है और उसी Code SHA के विरुद्ध दोबारा चलाया जाता है।

  5. Code SHA के सफल होने के बाद ही, अंतिम पहुँच-योग्य जारी किए गए टैग के बाद से merge किए गए PR और सीधे commits से शीर्ष CHANGELOG.md अनुभाग जनरेट करें। प्रविष्टियाँ उपयोगकर्ता-केंद्रित और डुप्लिकेट-रहित रखें। जब कोई अलग दिशा में गया जारी टैग या बाद का forward-port पहले से जारी PR को दोबारा संबद्ध करता है, तो उसे स्पष्ट रूप से --shipped-ref के रूप में दें।

  6. केवल CHANGELOG.md को commit करें। यह commit Release SHA है। Code SHA से Release SHA तक का पूरा diff ठीक CHANGELOG.md होना आवश्यक है; कोई भी अन्य परिवर्तित पथ रिलीज़ को चरण 2 पर वापस भेज देता है।

  7. प्रमाण के पुनः उपयोग को सक्षम करके Release SHA के लिए SHA-पिन किया हुआ Full Release Validation चलाएँ। हल्के parent को changelog-only-release-v1 दर्ज करना, सफल Code SHA की ओर संकेत करना और किसी उत्पाद child lane को dispatch नहीं करना चाहिए। यह उत्पाद प्रमाण का पुनः उपयोग करता है; पैकेज bytes का नहीं।

  8. Release SHA/tag के विरुद्ध preflight_only=true के साथ OpenClaw NPM Release चलाएँ। सफल preflight_run_id सहेजें। यह अंतिम चेंजलॉग शामिल करने वाले सटीक पैकेज bytes को build और जाँचता है।

  9. Release SHA को टैग करें, फिर किसी भी सत्यापन को दोबारा dispatch करने के बजाय सफल Release-SHA validation parent और npm प्रीफ़्लाइट के साथ candidate helper चलाएँ:

    bash
    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, अनुरोधित पैकेज सेट, अपरिवर्तनीय पैकेज आर्टिफ़ैक्ट ट्यूपल और अंतिम रजिस्ट्री रीडबैक आर्टिफ़ैक्ट आवश्यक हैं; किसी सफल विरासती रिलीज़-रेफ़ रन को स्वीकार नहीं किया जाता।

    फिर प्रकाशित [email protected] या openclaw@beta पैकेज के विरुद्ध प्रकाशनोत्तर पैकेज स्वीकृति चलाएँ। यदि पुश की गई या प्रकाशित पूर्व-रिलीज़ में सुधार आवश्यक हो, तो अगली मेल खाती पूर्व-रिलीज़ संख्या बनाएँ; पुरानी को कभी हटाएँ या दोबारा न लिखें।

  10. विफल प्रकाशन प्रयास पर, रिलीज़ SHA को अपरिवर्तित रखें, जब तक विफलता किसी उत्पाद या चेंजलॉग दोष को सिद्ध न करे। सफल अपरिवर्तनीय चाइल्ड और आर्टिफ़ैक्ट फिर से शुरू करें; पहले से सफल हो चुके पैकेज संस्करण को कभी दोबारा बिल्ड या प्रकाशित न करें।

  11. स्थिर रिलीज़ के लिए, केवल तभी आगे बढ़ें जब जाँची गई बीटा या रिलीज़ कैंडिडेट के पास आवश्यक सत्यापन साक्ष्य हों। स्थिर npm प्रकाशन भी OpenClaw Release Publish से होकर जाता है और preflight_run_id के माध्यम से सफल प्रीफ़्लाइट आर्टिफ़ैक्ट का पुनः उपयोग करता है। स्थिर macOS रिलीज़ तत्परता के लिए पैकेज किए गए .zip, .dmg, .dSYM.zip और main पर अपडेट किया गया appcast.xml भी आवश्यक हैं; रिलीज़ एसेट सत्यापित होने के बाद macOS प्रकाशन वर्कफ़्लो हस्ताक्षरित ऐपकास्ट को सार्वजनिक main पर स्वतः प्रकाशित करता है, या यदि ब्रांच सुरक्षा सीधे पुश को रोकती है तो ऐपकास्ट 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 डिस्पैच करता है और प्रकाशन से पहले तीनों एसेट सत्यापित करता है।

  12. प्रकाशन के बाद, npm प्रकाशनोत्तर सत्यापक चलाएँ, प्रकाशनोत्तर चैनल प्रमाण की आवश्यकता होने पर वैकल्पिक स्वतंत्र प्रकाशित-npm Telegram E2E चलाएँ, आवश्यकता होने पर dist-tag प्रमोशन करें, जनरेट किए गए GitHub रिलीज़ पृष्ठ को सत्यापित करें, रिलीज़ घोषणा चरण चलाएँ, फिर स्थिर रिलीज़ को पूर्ण घोषित करने से पहले स्थिर main समापन पूरा करें।

स्थिर main समापन

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

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

OpenClaw Stable Main Closeout स्थिर प्रकाशन के बाद भेजे गए संस्करण, चेंजलॉग और ऐपकास्ट वाले main पुश से शुरू होता है। यह भेजे गए टैग को उसके पूर्ण रिलीज़ सत्यापन और प्रकाशन रन से बाँधने के लिए अपरिवर्तनीय प्रकाशनोत्तर साक्ष्य पढ़ता है, फिर स्थिर main स्थिति, रिलीज़, अनिवार्य स्थिर सोक और अवरोधक प्रदर्शन साक्ष्य सत्यापित करता है। यह GitHub रिलीज़ में अपरिवर्तनीय समापन मैनिफ़ेस्ट और चेकसम संलग्न करता है। स्वचालित पुश ट्रिगर उन विरासती रिलीज़ को छोड़ देता है जो अपरिवर्तनीय प्रकाशनोत्तर साक्ष्य से पहले की हैं और उस छोड़े जाने को कभी पूर्ण समापन नहीं मानता।

पूर्ण समापन के लिए दोनों एसेट और मेल खाता चेकसम आवश्यक हैं। आंशिक मैनिफ़ेस्ट समान बाइट्स दोबारा जनरेट करने के लिए अपने दर्ज main SHA और रोलबैक अभ्यास को पुनः चलाता है, फिर अनुपस्थित चेकसम संलग्न करता है; अमान्य जोड़ी या मैनिफ़ेस्ट के बिना चेकसम अवरोधक बने रहते हैं। रोलबैक अभ्यास रिपॉज़िटरी चरों के बिना पुश-ट्रिगर किया गया रन समापन पूरा किए बिना छोड़ दिया जाता है; अनुपस्थित या 90 दिन से अधिक पुराना अभ्यास रिकॉर्ड अब भी मैन्युअल साक्ष्य-समर्थित समापन को रोकता है। निजी पुनर्प्राप्ति कमांड केवल अनुरक्षकों वाली रनबुक में रहते हैं। मैन्युअल डिस्पैच का उपयोग केवल साक्ष्य-समर्थित स्थिर समापन की मरम्मत या पुनः संचालन के लिए करें।

यदि रिलीज़ प्रकाशन पैरेंट केवल अपरिवर्तनीय npm/Plugin साक्ष्य संलग्न होने के बाद विफल हुआ हो, तो पहले प्रत्येक स्थिर प्लेटफ़ॉर्म एसेट की मरम्मत करके उसे प्रकाशित करें। फिर कोई अनुरक्षक allow_failed_publish_recovery=true के साथ समापन को मैन्युअल रूप से डिस्पैच कर सकता है; वह मोड केवल पूर्ण हो चुके विफल पैरेंट को स्वीकार करता है और सामान्य macOS/ऐपकास्ट जाँचों के साथ-साथ सटीक 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 चलाएँ। यह प्रत्येक नियतात्मक रिलीज़ जनरेटर चलाता है जिसमें संस्करण/कॉन्फ़िग/API परिवर्तन के बाद सामान्यतः विचलन होता है: Plugin संस्करण, npm श्रिंकरैप, Plugin इन्वेंटरी, आधार कॉन्फ़िग स्कीमा, बंडल किए गए चैनल कॉन्फ़िग मेटाडेटा, कॉन्फ़िग दस्तावेज़ बेसलाइन, 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 तब दें, जब पैकेज स्वीकृति को रिलीज़ पैकेज विनिर्देश से अलग प्रकाशित पैकेज उपयोग करना हो। evidence_package_spec तब दें, जब रिलीज़ साक्ष्य रिपोर्ट को Telegram E2E बाध्य किए बिना यह प्रमाणित करना हो कि सत्यापन प्रकाशित npm पैकेज से मेल खाता है।

    bash
    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 और परीक्षणाधीन पैकेज—दोनों के रूप में करता है, ताकि यह उम्मीदवार अपडेट कमांड के प्रबंधित रीस्टार्ट पथ का परीक्षण करे।

    उदाहरण:

    bash
    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 [email protected] -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 चाइल्ड को देता है।

    bash
    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 प्रकाशन को क्रमबद्ध करता है, ताकि मुख्य पैकेज उसके बाह्यीकृत Plugins से पहले प्रकाशित न हो; 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 पर लक्षित होना चाहिए, या GitHub का नवीनतम रीडायरेक्ट उसी रिलीज़ की ओर इंगित करता है यह सत्यापित करने के बाद ही releases/latest/download/... पर; केवल सहयोगी रिपॉज़िटरी के रिलीज़ पृष्ठ से लिंक न करें।

  • रिलीज़ जाँच अब एक अलग मैन्युअल वर्कफ़्लो में चलती हैं: 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/रिलीज़ वर्कफ़्लो रेफ़ से डिस्पैच करना चाहिए, ताकि वर्कफ़्लो लॉजिक और सीक्रेट नियंत्रित रहें।

  • 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 सत्यापित करने के लिए [email protected] 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 खोलता है); पैकेज किए गए ऐप में गैर-डीबग बंडल आईडी, गैर-रिक्त Sparkle फ़ीड URL और उस रिलीज़ संस्करण के मानक Sparkle बिल्ड न्यूनतम के बराबर या उससे अधिक CFBundleVersion बने रहने चाहिए।

रिलीज़ टेस्ट बॉक्स

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

bash
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 के साथ वही सहायक चलाएँ:

bash
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 वाली Package Acceptance, 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, Package Acceptance तथा रिलीज़-पथ Docker जाँच में पुनः उपयोग करता है। इससे सभी पैकेज-संबंधी बॉक्स समान बाइट पर रहते हैं और बार-बार पैकेज बिल्ड से बचते हैं। जब बीटा npm पर पहले से उपलब्ध हो, तो [email protected] सेट करें, ताकि रिलीज़ जाँच जारी किया गया पैकेज एक बार डाउनलोड करें, dist/build-info.json से उसका बिल्ड स्रोत SHA निकालें और उस आर्टिफ़ैक्ट का क्रॉस-OS, Package Acceptance, रिलीज़-पथ Docker और पैकेज Telegram लेन में पुनः उपयोग करें।

क्रॉस-OS OpenAI इंस्टॉल स्मोक, repo/org वेरिएबल सेट होने पर OPENCLAW_CROSS_OS_OPENAI_MODEL और अन्यथा openai/gpt-5.6-luna का उपयोग करता है, क्योंकि यह लेन सबसे सक्षम मॉडल का बेंचमार्क करने के बजाय पैकेज इंस्टॉल, ऑनबोर्डिंग, Gateway स्टार्टअप और एक लाइव एजेंट टर्न प्रमाणित करती है। विस्तृत लाइव प्रदाता मैट्रिक्स मॉडल-विशिष्ट कवरेज का स्थान बना रहता है।

रिलीज़ चरण के अनुसार इन प्रकारों का उपयोग करें:

bash
# उत्पाद-पूर्ण 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 [email protected] \  -f [email protected] \  -f npm_telegram_provider_mode=mock-openai

किसी केंद्रित सुधार के बाद पहले पुनः रन के रूप में पूर्ण छत्र का उपयोग न करें। यदि कोई बॉक्स विफल होता है, तो अगले प्रमाण के लिए विफल चाइल्ड वर्कफ़्लो, जॉब, Docker लेन, पैकेज प्रोफ़ाइल, मॉडल प्रदाता या QA लेन का उपयोग करें। पूर्ण छत्र को दोबारा केवल तभी चलाएँ, जब सुधार ने साझा रिलीज़ ऑर्केस्ट्रेशन बदला हो या पहले के सभी-बॉक्स प्रमाण को अप्रचलित कर दिया हो। छत्र का अंतिम सत्यापनकर्ता रिकॉर्ड की गई चाइल्ड वर्कफ़्लो रन आईडी की फिर से जाँच करता है, इसलिए किसी चाइल्ड वर्कफ़्लो के सफलतापूर्वक पुनः चलने के बाद केवल विफल Verify full validation पैरेंट जॉब को पुनः चलाएँ।

rerun_group=all पिछले सफल छत्र रन का पुनः उपयोग कर सकता है, जब रिलीज़ प्रोफ़ाइल, प्रभावी सोक सेटिंग और सत्यापन इनपुट मेल खाते हों तथा या तो लक्ष्य SHA समान हो या नया लक्ष्य ऐसा वंशज हो जिसका परिवर्तित पथों का पूरा समुच्चय ठीक CHANGELOG.md हो। सटीक-लक्ष्य पुनः उपयोग 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 आवश्यक है; पूर्ण/सभी रन पैकेज स्वीकृति के भीतर मानक पैकेज 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 जोड़ें:

bash
gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.PATCHgh 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 के साथ पैकेज स्वीकृति चलाता है। पैकेज स्वीकृति माइग्रेशन, अपडेट, रूट-प्रबंधित VPS अपग्रेड, कॉन्फ़िगर किए गए प्रमाणीकरण का अपडेट रीस्टार्ट, लाइव ClawHub Skill इंस्टॉल, पुराने 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 के साथ पैकेज स्वीकृति का उपयोग करें।

यह अधिकांश उस पैकेज/अपडेट कवरेज का GitHub-मूल प्रतिस्थापन है जिसके लिए पहले Parallels आवश्यक था। OS-विशिष्ट ऑनबोर्डिंग, इंस्टॉलर और प्लेटफ़ॉर्म व्यवहार के लिए क्रॉस-OS रिलीज़ जाँच अभी भी महत्वपूर्ण हैं, लेकिन पैकेज/अपडेट उत्पाद सत्यापन में पैकेज स्वीकृति को प्राथमिकता दी जानी चाहिए।

अपडेट और Plugin सत्यापन के लिए मानक चेकलिस्ट अपडेट और Plugin का परीक्षण है। इसका उपयोग यह तय करते समय करें कि कौन-सी स्थानीय, Docker, पैकेज स्वीकृति या रिलीज़-जाँच लेन किसी Plugin इंस्टॉल/अपडेट, डॉक्टर सफ़ाई या प्रकाशित-पैकेज माइग्रेशन बदलाव को प्रमाणित करती है। प्रत्येक स्थिर 2026.4.23+ पैकेज से व्यापक प्रकाशित अपडेट माइग्रेशन एक अलग मैन्युअल Update Migration वर्कफ़्लो है, जो पूर्ण रिलीज़ CI का भाग नहीं है।

पुरानी पैकेज-स्वीकृति शिथिलता जानबूझकर समय-सीमित है। 2026.4.25 तक के पैकेज npm पर पहले से प्रकाशित मेटाडेटा अंतराल के लिए संगतता पथ का उपयोग कर सकते हैं: टारबॉल से अनुपस्थित निजी QA इन्वेंटरी प्रविष्टियाँ, अनुपस्थित gateway install --wrapper, टारबॉल-व्युत्पन्न git फ़िक्स्चर में अनुपस्थित पैच फ़ाइलें, अनुपस्थित स्थायी update.channel, पुराने Plugin इंस्टॉल-रिकॉर्ड स्थान, अनुपस्थित मार्केटप्लेस इंस्टॉल-रिकॉर्ड स्थायित्व और plugins update के दौरान कॉन्फ़िगरेशन मेटाडेटा माइग्रेशन। प्रकाशित 2026.4.26 पैकेज पहले से जारी स्थानीय बिल्ड मेटाडेटा स्टैम्प फ़ाइलों के लिए चेतावनी दे सकता है। बाद के पैकेजों को आधुनिक पैकेज अनुबंधों को पूरा करना होगा; वही अंतराल रिलीज़ सत्यापन को विफल कर देते हैं।

जब रिलीज़ का प्रश्न किसी वास्तविक इंस्टॉल किए जा सकने वाले पैकेज के बारे में हो, तब अधिक व्यापक पैकेज स्वीकृति प्रोफ़ाइल का उपयोग करें:

bash
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 [email protected]

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

  • 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+ केवल-npm विस्तारित-स्थिर पथ इस ऑर्केस्ट्रेटर का उपयोग नहीं करता। यह नियमित वर्कफ़्लो विश्वसनीय-प्रकाशक वर्कफ़्लो को रिलीज़ के लिए आवश्यक क्रम में ऑर्केस्ट्रेट करता है:

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

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

bash
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 पर स्थिर प्रकाशन:

bash
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 पर स्थिर प्रोमोशन स्पष्ट रूप से निर्दिष्ट है:

bash
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 डिस्पैच करें और ref के माध्यम से पूर्ण लक्षित रिलीज़ SHA दें। बूटस्ट्रैप वर्कफ़्लो को स्वयं रिलीज़ टैग या ब्रांच से कभी न चलाएँ:

bash
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+ केवल-npm विस्तारित-स्थिर पथ नहीं है।

नियमित समन्वित स्थिर रिलीज़ बनाते समय:

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

dist-tag परिवर्तन रिलीज़ लेजर रेपो में रहता है क्योंकि इसके लिए अभी भी NPM_TOKEN आवश्यक है, जबकि सोर्स रेपो केवल-OIDC प्रकाशन बनाए रखता है। इससे प्रत्यक्ष प्रकाशन पथ और पहले-बीटा प्रचार पथ दोनों प्रलेखित और ऑपरेटर को दृश्यमान रहते हैं।

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

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

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

संबंधित

Was this useful?
On this page

On this page