रिलीज़ प्रदर्शन स्वीप

यह पृष्ठ मई 2026 के OpenClaw प्रदर्शन, पैकेज-आकार, निर्भरता, और shrinkwrap सफाई के पीछे के साक्ष्य को दर्ज करता है। यह सार्वजनिक ब्लॉग पोस्ट का तकनीकी साथी है। यहां दो ऑडिट जोड़े गए हैं:

• रिलीज़ प्रदर्शन स्वीप: v2026.5.28 से लेकर स्थिर v2026.4.23 तक के GitHub Releases, OpenClaw Performance workflow, profile=smoke, mock-provider lane का उपयोग करते हुए। अधिकांश टैग पंक्तियां एक नमूना हैं; v2026.5.27 और v2026.5.28 पंक्तियां नवीनतम repeat-3 release-branch आर्टिफैक्ट का उपयोग करती हैं।
• अप्रैल का पहले का संदर्भ: v2026.4.1 से v2026.5.2 तक प्रकाशित clawgrit-reports mock-provider baselines, जिनका उपयोग केवल टूटे हुए अप्रैल-अंत रिलीज़ को सार्वजनिक प्रदर्शन baseline मानने से बचने के लिए किया गया।
• इंस्टॉल footprint स्वीप: अस्थायी पैकेजों में ताज़ा npm install --ignore-scripts इंस्टॉल, आकार के लिए du -sk node_modules और package-instance गिनतियों के लिए node_modules walk के साथ।
• npm पैकेज आकार स्वीप: प्रकाशित रिलीज़ के लिए npm pack openclaw@<version> --dry-run --json, compressed tarball आकार, unpacked आकार, और फ़ाइल गिनती रिकॉर्ड करते हुए।

​

Snapshot

प्रदर्शन कवरेज: 77 अनुरोधित रिलीज़, 74 artifact-backed points, और 3 अनुपलब्ध CI runs। नवीनतम मापा गया स्थिर बिंदु: v2026.5.28।

​

इंस्टॉल Footprint टाइमलाइन

​

5.28 में क्या बदला

v2026.5.27 और v2026.5.28 के बीच सफ़ाई ने क्षमताओं को हटाने के बजाय डिफ़ॉल्ट-इंस्टॉल ग्राफ़ को घटाया।

​

मुख्य संख्याएँ

अप्रैल के अंत वाली टूटी हुई पंक्तियों को सार्वजनिक प्रदर्शन बेसलाइन के रूप में उपयोग न करें। v2026.4.23 और v2026.4.29 उपयोगी रिग्रेशन साक्ष्य हैं, लेकिन बड़े 14x-शैली के डेल्टा ज़्यादातर एक खराब रिलीज़ लाइन से रिकवरी का वर्णन करते हैं। ब्लॉग कथा के लिए, पहले की अप्रैल प्रकाशित बेसलाइन को पैमाने के रूप में उपयोग करें: पहले की अप्रैल बेसलाइन प्रकाशित clawgrit-reports मॉक-प्रोवाइडर रन से v2026.4.14 है। उस रन ने repeat 3 का उपयोग किया और केवल इसलिए विफल हुआ क्योंकि डायग्नोस्टिक टाइमलाइन उत्सर्जित नहीं हुई थी; कोल्ड, वॉर्म, और RSS मीडियन अब भी मोटे पैमाने के रूप में उपयोगी हैं। इसे कथात्मक संदर्भ मानें, रिलीज़-गेट आँकड़ा नहीं। मई स्वीप के भीतर, नवीनतम रिलीज़-branch पंक्ति v2026.5.2 से उल्लेखनीय रूप से आगे बढ़ी: पिछली स्थिर रिलीज़ की तुलना में:

​

इंस्टॉल फ़ुटप्रिंट

​

npm पैकेज आकार

2026.5.12 चेंजलॉग में दिखने वाला plugin-एक्सट्रैक्शन माइलस्टोन है: Amazon Bedrock, Bedrock Mantle, Slack, OpenShell sandbox, Anthropic Vertex, Matrix, और WhatsApp को core निर्भरता पथ से बाहर ले जाया गया ताकि उनके निर्भरता कोन हर core इंस्टॉल के बजाय उन plugins के साथ इंस्टॉल हों।

​

Kova एजेंट टर्न सारांश

अप्रैल स्थिर लाइन में दो अलग-अलग कहानियाँ हैं। पहले का अप्रैल धीमा था लेकिन पहचाने जाने योग्य था। अप्रैल के अंत में यह रिग्रेशन क्लिफ बन गया। v2026.5.2 वह जगह है जहाँ मॉक-प्रोवाइडर लेन पहली बार 3-5s रेंज में गिरती है और दिए गए स्वीप में लगातार पास होना शुरू करती है। पहले प्रकाशित संदर्भ: दिया गया स्वीप:

​

स्रोत प्रोब

17 सफल पुराने refs के लिए स्रोत प्रोब छोड़े गए क्योंकि उन स्रोत ट्री में अभी आवश्यक प्रोब एंट्री पॉइंट नहीं थे। उन refs के लिए एजेंट-टर्न मीट्रिक अब भी मौजूद हैं। प्रतिनिधि स्रोत-प्रोब बिंदु: v2026.5.22 CLI स्वास्थ्य उछाल इस तालिका में दिखाई देता है, भले ही agent-turn लेन अब भी पास हुई। लक्षित CLI या Gateway रिग्रेशन की जाँच करते समय स्रोत जांचें रखें।

​

इंस्टॉल फुटप्रिंट ऑडिट

डिपेंडेंसी नमूने हर महीने की एक स्थिर रिलीज़, साथ ही 2026.5.22 shrinkwrap-परिचय घटना और नवीनतम 2026.5.28 रिलीज़ का उपयोग करते हैं।

​

Shrinkwrap सीमा

प्रकाशित tarball निरीक्षण सीमा की पुष्टि करता है: महत्वपूर्ण अंतर: shrinkwrap स्वयं समस्या नहीं है। v2026.5.28 अब भी रूट shrinkwrap के साथ शिप होता है। समस्या पैकेज आकार में थी, जिसने npm से एक बड़ा नेस्टेड OpenClaw डिपेंडेंसी ट्री और सभी 12 @napi-rs/canvas प्लेटफ़ॉर्म पैकेज materialize करवा दिए। v2026.5.28 में नेस्टेड ट्री छोटा है, और canvas प्लेटफ़ॉर्म fanout अब स्थानीय ऑडिट में नहीं आता। shrinkwrap और मेंटेनर-स्तर के पैकेज checks की सरल अंग्रेज़ी व्याख्या के लिए, npm shrinkwrap देखें।

​

सप्लाई-चेन व्याख्या

डिपेंडेंसी संख्या एक परिचालन सुरक्षा मेट्रिक है, केवल इंस्टॉल-आकार मेट्रिक नहीं। हर पैकेज मेंटेनरों, tarballs, ट्रांज़िटिव अपडेट्स, वैकल्पिक native binaries, और install-time behaviors के उस सेट को बढ़ाता है जिस पर ऑपरेटरों को भरोसा करना पड़ता है। cleanup दिशा यह है:

• भारी और वैकल्पिक क्षमताओं को डिफ़ॉल्ट core install से बाहर रखें
• Plugin packages अपने runtime dependency graph के मालिक हों
• Gateway startup के दौरान runtime package-manager repair से बचें
• deterministic installs बनाए रखें, बिना all-platform native package materialization कराए
• package acceptance और measurement paths में install scripts disabled रखें
• publishing से पहले nested dependency trees और native optional dependency explosions पकड़ें

संबंधित docs:

• Plugin dependency resolution
• Plugin inventory
• Full release validation