SSD Nodes Learn Hosting plans →
मार्गदर्शक Matt Connorद्वारे Matt Connor

DeepSeek Harness install आणि version errors दुरुस्त करा

npm वरील प्रत्येक DeepSeek Harness build अजून prerelease आहे. अचूक dsh version pin करा, npx cache साफ करा आणि Node सोबत कोणते npm येते ते तपासा.

DeepSeek Harness ची स्थापना प्रत्यक्षात काय आहे

DeepSeek Harness ची स्थापना एका command ने होते: npx @deepseek-ai/dsh web. कोणताही installer नाही आणि configure करण्यासाठी कोणतीही service नाही. लोकांना येणाऱ्या बहुतेक अडचणी प्रत्यक्षात installation शी संबंधित नसतात. त्या version resolution शी संबंधित असतात: @deepseek-ai/dsh ची कोणती build npx ने आज चालवण्याचे ठरवले आणि तुमची Node.js आवृत्ती ती चालवू शकते का. ती सुरू झाल्यावर दाखवलेला address localhost शी bind केलेला असतो. Web UI केवळ 127.0.0.1:3080 वरच प्रतिसाद का देते ही या पृष्ठावरील समस्यांपेक्षा वेगळी समस्या आहे.

खालील सर्व बाबींवर दोन तथ्यांचा परिणाम होतो. पहिले, आतापर्यंत npm वर प्रकाशित झालेली @deepseek-ai/dsh ची प्रत्येक आवृत्ती prerelease आहे. त्यांपैकी बहुतेक release candidates (-rc.N) आहेत. तसेच 30 August 2026 पासून alpha builds (-alpha.N) देखील उपलब्ध आहेत. latest tag release candidate कडे निर्देश करतो. 6 October 2026 रोजी ती आवृत्ती 0.2.0-rc.2 आहे. ती 29 September 2026 रोजी प्रकाशित झाली. दुसरे, प्रकल्पाच्या README नुसार harness सध्या developer preview मध्ये आहे, त्यात वेगाने बदल होत आहेत आणि compatibility-breaking changes येऊ शकतात. मागील आठवड्यात कार्यरत असलेला flag या आठवड्यात काढून टाकलेला असू शकतो. त्यावर आधारित काहीही तयार करण्यापूर्वी आवृत्ती निश्चित करा.

आधी काही संज्ञा समजून घेऊ. dsh हे DeepSeek Harness चे command line tool आहे. Node.js हे त्याला आवश्यक असलेले JavaScript runtime आहे. npx हा npm (node package manager) सोबत उपलब्ध होणारा package runner आहे. तो package कायमस्वरूपी install करण्याऐवजी आवश्यकतेनुसार fetch करतो. त्या वाक्यात harness या शब्दाचा अर्थ स्पष्ट नसल्यास, agent harness म्हणजे model भोवती चालणारा program, जो loop, tools, permissions आणि session state हाताळतो. म्हणून तुम्ही निवडलेला नसलेला version number तुमचा agent कसा वागतो हे बदलू शकतो.

dsh साठी Node.js ची कोणती आवृत्ती आवश्यक आहे?

repository च्या root मधील package.json मध्ये "engines": {"node": "^22.19.0 || >=24.0.0"} घोषित केले आहे. 6 October 2026 रोजी repository version 0.2.1-alpha.1 वर असताना ही नोंद वाचण्यात आली. त्यामुळे 22 line मधील Node 22.19.0 किंवा त्यानंतरची आवृत्ती, किंवा Node 24 आणि त्यावरील आवृत्ती आवश्यक आहे. Node 20 समर्थित नाही.

इतर काही करण्यापूर्वी तुमच्याकडे कोणती आवृत्ती आहे ते तपासा.

node -v
npm -v

येथे अनेकांना आश्चर्य वाटणारा मुद्दा आहे. प्रकाशित @deepseek-ai/dsh package मध्ये स्वतःचे engines field नाही. फक्त monorepo root मध्ये ते घोषित केले आहे आणि ती root file npm वर प्रकाशित केली जात नाही. त्यामुळे npm कडे तपासण्यासाठी काहीही नसते. म्हणून ते EBADENGINE warning दाखवत नाही आणि काहीही नाकारत नाही. Node 20 वर install यशस्वी झाल्यासारखे दिसते. प्रत्यक्ष failure नंतर येतो, जेव्हा load झालेला code तुमच्या runtime मध्ये उपलब्ध नसलेली syntax किंवा API वापरतो. शोधण्यासाठी एकच स्थिर error string नाही, कारण प्रथम कोणते module load होते त्यावर प्रथम कोणती line fail होईल हे अवलंबून असते. crash वाचण्याऐवजी node -v वाचा.

तुमचा Node जुना असल्यास, VPS वर nvm (node version manager) हा सर्वांत कमी हस्तक्षेप करणारा उपाय आहे. तो तुमच्या home directory अंतर्गत install होतो आणि system Node मध्ये बदल करत नाही.

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.6/install.sh | bash
exec $SHELL -l
nvm install 24
nvm use 24
node -v

node -v ने आता v24. ने सुरू होणारी version दाखवली पाहिजे. shell अजूनही जुनी version दाखवत असल्यास, nvm shell function load झालेले नाही. नवीन login shell उघडा आणि पुन्हा प्रयत्न करा. 6 October 2026 रोजी Node 24 ही active LTS (long term support) line आहे आणि त्या तारखेची तिची नवीनतम release 24.21.0 आहे. खाली दिलेल्या दुसऱ्या कारणामुळेही ही अधिक योग्य निवड आहे.

npx दररोज वेगळी आवृत्ती का चालवते?

npx @deepseek-ai/dsh web मध्ये आवृत्ती दिलेली नसते. त्यामुळे npx रजिस्ट्रीकडे जाऊन latest tag सध्या ज्या आवृत्तीकडे निर्देश करतो ती आवृत्ती मागते. हा tag बदलत असतो आणि अनेकदा बदलतो. 0.1.0-rc.8 हे 19 August 2026 रोजी आले, म्हणजे 0.1.0-rc.7 नंतर दोन दिवसांनी. 6 October 2026 पर्यंत latest पुढे बदलून 0.2.0-rc.2 वर गेला होता. तो प्रत्येक वेळी बदलला की, तुमच्या नोंदींमध्ये असलेली command कोणतीही सूचना न देता आणि समोर changelog नसताना वेगळा code चालवू लागते.

तुम्ही command line वरून या प्रक्रियेतील प्रत्येक घटक तपासू शकता.

npm view @deepseek-ai/dsh dist-tags
npm view @deepseek-ai/dsh versions --json
npm view @deepseek-ai/dsh time --json

dist-tags हे latest सध्या कुठे निर्देश करतो ते दाखवते. 6 October 2026 रोजी latest आणि next दोन्ही 0.2.0-rc.2 कडे निर्देश करत होते. आणखी एक tag, alpha, 0.2.1-alpha.1 कडे निर्देश करत होता. यापैकी कोणताही tag वापरण्यासाठी स्थिर channel नाही. versions यादी अधिक महत्त्वाची आहे, कारण त्यात काही आवृत्ती क्रमांक गहाळ आहेत. 6 October 2026 रोजी या यादीत 0.0.1-rc.1 ते 0.2.1-alpha.1 पर्यंतच्या 30 आवृत्त्या होत्या. 0.0.1 मालिकेत -rc.2 नंतर थेट -rc.5 येते. 0.1.0 मालिकेत -rc.3 नंतर थेट -rc.6 येते. Alpha builds 0.1.2-alpha.2 आणि 0.1.3-alpha.2 पासून सुरू होतात. तसेच 0.1.4 मुळीच नाही. काही builds कधीही प्रकाशित झाले नाहीत म्हणून काही क्रमांक गहाळ आहेत. Alpha builds आणि release candidates याच यादीत एकत्र आहेत. Deploy script मध्ये पुढील -rc.N चा अंदाज लावल्यास command अयशस्वी होईल. त्यामुळे क्रमांक वाढवत मोजण्याऐवजी यादी वाचा.

npx जुनी आवृत्तीच का चालवत राहते?

ही तक्रार याच्या उलट आहे. तुम्ही कोणते npm चालवत आहात, यावर दोन्ही वर्तन अवलंबून असतात.

npx स्वतःची package directory ठेवते. ती tarball cache पेक्षा वेगळी असते आणि npm cache मधील _npx नावाच्या folder मध्ये असते. तिचा path दाखवा आणि तो तपासा.

npm config get cache
ls "$(npm config get cache)/_npx"

अनेक वर्षे npx ला एखाद्या bare package name साठी त्या directory मध्ये जे सापडेल तेच पुन्हा वापरता येत होते. ते registry ला पुन्हा विचारत नव्हते. npm 11.2.0 मध्ये हे बदलले. spec हा bare name किंवा version range असल्यास, npx आता manifest fetch करते. Registry ने नुकतेच परत केलेल्या resolved tarball शी cached copy जुळत असेल, तेव्हाच ती copy पुन्हा वापरते.

तुम्हाला कोणते वर्तन मिळेल हे तुमची Node release ठरवते, कारण Node मध्ये विशिष्ट npm आवृत्ती bundled असते:

  • Node 20.20.2 मध्ये npm 10.8.2 bundled आहे.
  • Node 22.19.0 मध्ये npm 10.9.3 bundled आहे.
  • Node 22.23.3 मध्ये, 6 October 2026 रोजीची सर्वात नवीन 22 release, npm 10.9.9 bundled आहे.
  • Node 24.19.0 मध्ये npm 11.17.0 bundled आहे.
  • Node 24.21.0 मध्ये, 6 October 2026 रोजीची सर्वात नवीन 24 release, npm 11.19.0 bundled आहे.

म्हणून अधिकृतरीत्या समर्थित असलेली संपूर्ण Node 22 line, 11.2.0 पेक्षा जुने npm release करते. Node 22 वर bare npx @deepseek-ai/dsh web काही आठवड्यांपूर्वी cache केलेला release candidate पुन्हा पुन्हा चालवत राहील. Node 24 वर तोच command प्रत्येक वेळी पुन्हा resolve होईल. एकच command, पण दोन वर्तन; आणि यापैकी कोणतेही वर्तन तुम्हाला warning देत नाही. Tool ची आवृत्ती विचारा:

npx @deepseek-ai/dsh --version

npx cache साफ करणे

npm 11.2.0 आणि त्यानंतरच्या आवृत्त्यांमध्ये यासाठी स्वतंत्र subcommands आहेत.

npm cache npx ls
npm cache npx rm --force

--force शिवाय npm सर्व entries पुसण्यास नकार देते आणि Please use --force to remove entire npx cache दाखवते. सर्व entries पुसण्याऐवजी key नुसार एक entry काढायची असल्यास प्रथम npm cache npx ls वापरा.

npm 10 मध्ये हे subcommands उपलब्ध नाहीत. त्यामुळे directory स्वतः delete करा.

rm -rf "$(npm config get cache)/_npx"

npm cache clean --force यासाठी उपयोगी नाही. ते _cacache, म्हणजे tarball store, साफ करते आणि _npx तशीच ठेवते. ही विभागणी नेमकी याच कारणामुळे npm ने नंतर npm cache npx subcommands जोडली. _npx साफ केल्याने कायमस्वरूपी काहीही गमावत नाही: त्यात downloaded packages असतात, तर तुमची harness state $DSH_HOME/profiles/<name> अंतर्गत असते आणि त्यावर परिणाम होत नाही.

अचूक release candidate कसा pin करावा?

-rc.N भागासह पूर्ण version string नमूद करा.

npx --yes @deepseek-ai/dsh@0.1.0-rc.7 web

या पृष्ठावरील उदाहरणांमध्ये 0.1.0-rc.7 वापरले आहे. तुम्ही प्रत्यक्ष तपासलेला build वापरा. 6 October 2026 रोजी latest tag हा 0.2.0-rc.2 कडे निर्देश करत होता.

Script मध्ये --yes महत्त्वाचे आहे. अन्यथा, npx ने यापूर्वी न पाहिलेला package install करण्यापूर्वी prompt दाखवतो आणि कधीही न येणाऱ्या उत्तराची प्रतीक्षा करतो.

अचूक version हा जलद मार्गही आहे. तुम्ही टाइप केलेल्या spec string वर npx cache directory चे नाव ठरवतो. अचूक version असल्यास, तो string तेथे आधीच install असलेल्या package id शी तपासतो आणि registry शी कोणताही संपर्क न करता package चालवतो. npm 11.2.0 आणि त्यानंतरच्या आवृत्त्यांमध्ये bare name वापरल्यास प्रत्येक start वेळी manifest fetch करावा लागतो.

Global install देखील याच प्रकारे pin करता येते आणि त्यासाठी command लहान असतो.

npm install -g @deepseek-ai/dsh@0.1.0-rc.7
dsh --version

@deepseek-ai/dsh@^0.1.0 साठी जुळणारी version सापडली नाही

या package साठी caret किंवा tilde range अपयशी ठरते. npm install -g @deepseek-ai/dsh@^0.1.0 error code ETARGET आणि ओळ No matching version found for @deepseek-ai/dsh@^0.1.0. यांसह उत्तर देते. Registry मध्ये समस्या नाही. हा semver नियम आहे: range मध्येच prerelease नमूद केलेली नसल्यास version range prerelease version शी जुळत नाही. या package चे प्रकाशित प्रत्येक build prerelease आहे, एकतर -rc.N किंवा -alpha.N. त्यामुळे ^0.1.0 कशाशीही जुळत नाही. अचूक version लिहा.

या नियमाचा एक उपयुक्त परिणाम आहे. Range नवीन release candidate कडे आपोआप बदलू शकत नसल्यामुळे, अंशतः pin केलेली स्थिती समजून घेण्याची गरज राहत नाही. तुम्ही एकतर अचूक version वापरत असता किंवा बदलणारा tag वापरत असता.

npx वापरावे की dsh जागतिक पातळीवर install करावे?

पहिल्यांदा पाहणी करण्यासाठी npx वापरा, कारण आता कसे साफ करायचे हे माहीत असलेल्या cache directory व्यतिरिक्त काहीही मागे राहत नाही. रीबूटनंतरही कार्यरत राहणे आवश्यक असलेल्या गोष्टींसाठी pinned global install वापरा. उदाहरणार्थ, तुम्ही VPS वर सतत चालू ठेवणारा coding agent.

दोन्ही पद्धती वापरलेल्या server वर त्यांचे परिणाम वेगळे असू शकतात. त्यामुळे त्यांची तुलना करा.

which dsh
dsh --version
npx @deepseek-ai/dsh --version

which dsh यशस्वी global install नंतर लगेच काहीही सापडत नसेल, तर npm ची global bin directory तुमच्या PATH मध्ये नसणे हे जवळजवळ नेहमीचे कारण असते. root दाखवण्यासाठी npm prefix -g चालवा. त्याखालील bin folder मध्ये binaries असतात.

सुरक्षेसंबंधी एक मुद्दा लक्षात ठेवा. npx एखादी नवीन गोष्ट resolve करताना registry मधून code fetch करून execute करते. Server वर हा केवळ सैद्धांतिक धोका नसून प्रत्यक्ष exposure आहे. Pinning हा उपायाचा एक भाग आहे. उर्वरित माहिती npm supply chain attacks server पर्यंत कशा पोहोचतात येथे आहे.

पुनरुत्पादनक्षमतेसाठी developer preview चा अर्थ

0.1.0-rc.6 13 August 2026 रोजी प्रकाशित झाले आणि 0.1.0-rc.7 17 August 2026 रोजी प्रकाशित झाले. त्यांच्यात चार दिवसांचे अंतर होते. त्यानंतरही हा वेग कमी झालेला नाही: 19 August ते 3 October 2026 दरम्यान आणखी 23 आवृत्त्या प्रकाशित झाल्या. त्यामध्ये 28 September रोजी प्रकाशित झालेले 0.2.0-rc.1 आणि त्याच्या पुढील दिवशी प्रकाशित झालेले 0.2.0-rc.2 यांचा समावेश आहे. या वेगाने, एका महिन्यापूर्वी लिहिलेल्या सूचनांमध्ये आता अस्तित्वात नसलेली command line असू शकते. या पृष्ठालाही ते लागू होते. तुम्ही लिहून ठेवलेल्या प्रत्येक आवृत्तीच्या दाव्याला, तुमच्या स्वतःच्या नोंदींसह, तारीख द्या.

Preview वापरताना दोन सवयी उपयुक्त ठरतात. प्रत्येक command आणि प्रत्येक script मध्ये अचूक आवृत्ती pin करा, जेणेकरून server पुन्हा तयार केल्यावर तोच harness मिळेल. त्यानंतर कोणत्याही मार्गदर्शकाऐवजी pinned build कडून मिळणारे help output वाचा.

npx @deepseek-ai/dsh@0.1.0-rc.7 --help
npx @deepseek-ai/dsh@0.1.0-rc.7 web --dump-config

पुनरुत्पादनक्षमतेचा दुसरा भाग म्हणजे profile. dsh --profile <name> $DSH_HOME/profiles/<name> येथे साठवलेला profile boot करतो. web आणि headless profiles पहिल्यांदा वापरताना shipped templates मधून स्वतः तयार होतात. harness त्याची API key, model आणि endpoint settings वाचतो ती directory हीच आहे. त्यामुळे pinned version आणि कार्यरत configuration या दोन स्वतंत्र गोष्टी योग्यरीत्या निश्चित कराव्या लागतात. In-box bundles सध्या चालू असलेल्या dsh installation मधून resolve होतात. याचा अर्थ pinned version बदलल्यास ते bundles देखील बदलतात. Out-of-tree plugins वेगळ्या पद्धतीने कार्य करतात. ते profile directory मध्ये असतात आणि dsh plugin --profile <name> add <package> त्याचे arguments pnpm कडे पाठवून ते install करते. त्यामुळे pnpm तुमच्या PATH मध्ये असणे आवश्यक आहे. ते नसल्यास dsh हे कारण स्पष्टपणे सांगते. तुम्ही जोडलेला प्रत्येक plugin तुमच्या agent कडे असलेल्या त्याच permissions सह चालतो. त्यामुळे install करण्यापूर्वी plugin कशापर्यंत पोहोचू शकतो हे तपासणे योग्य ठरते. Profile मधील स्वतःची package.json file या plugins ना pin करते. त्यामुळे संपूर्ण pin साठी एका नव्हे, तर दोन files आवश्यक असतात.

Server वर Python tools isolated environments मध्ये ठेवले असतील, तर हा विभाग परिचित वाटेल: tool आणि त्यात जोडलेल्या गोष्टी स्वतंत्र ठिकाणी pin केल्या जातात. harness सुरू झाल्यावर पुढील प्रश्न साधारणपणे versions पेक्षा networking संदर्भात असतो. त्या टप्प्यावर remote VPS वर dsh Web UI पर्यंत पोहोचणे आणि VPS वर DeepSeek Harness install करण्याचे सविस्तर walkthrough उपयुक्त ठरतात.

तुम्हाला प्रत्यक्ष दिसणाऱ्या argument त्रुटी

या त्रुटी CLI च्या स्वतःच्या parser मधून येतात आणि प्रत्येक त्रुटीत नेमकी समस्या नमूद केलेली असते. विविध builds मध्ये त्यातील wording बहुतांश स्थिर राहिले आहे; मात्र पूर्णपणे नाही. त्यामुळे खालील messages ची 0.2.0-rc.2 विरुद्ध 6 October 2026 रोजी पडताळणी करण्यात आली.

error: --profile <name> is required

तुम्ही npx @deepseek-ai/dsh कोणत्याही subcommand किंवा profile शिवाय चालवले. Bare command profile सुरू करते, त्यामुळे तिला नाव आवश्यक असते. dsh web हे --profile शिवाय चालते, कारण parser पहिला bare word profile name म्हणून वाचतो. त्यामुळे ते वितरित केलेले web profile तुमच्यासाठी सुरू करते.

error: --patch needs a path

--patch नंतर काहीही दिले गेले नाही. हा flag पुन्हा वापरता येतो आणि प्रत्येक वेळी त्याला एका file path ची आवश्यकता असते.

error: --dump-config and --dump-default-config are mutually exclusive

यापैकी एक निवडा. 0.2.0-rc.2 मध्ये, 6 October 2026 रोजी latest ने निर्देश केलेल्या build मध्ये, message मध्ये तिसऱ्या flag चे नाव येते आणि ते error: --dump-config, --dump-default-config, and --dump-config-schema are mutually exclusive असे दिसते. कारण profile entries आणि patches साठी JSON Schema छापणारे --dump-config-schema आता या दोन्ही flags मध्ये समाविष्ट झाले आहे. --dump-default-config वितरित केलेल्या bundle layers छापते आणि कोणतेही --patch स्वीकारत नाही. --dump-config एखाद्या profile साठी composed configuration छापते. ही सर्व commands harness सुरू न करता output छापून exit होतात. त्यामुळे नवीन release candidate ने configuration मध्ये केलेले बदल पाहण्याचा हा सुरक्षित मार्ग आहे.

error: plugin needs pnpm arguments to forward (e.g. add <package>)

पुढे पाठवण्यासाठी dsh plugin --profile <name> ला काहीही दिले गेले नाही. Subcommand profile नसल्यास तो profile initialize करतो आणि त्यानंतर command line मधील उर्वरित भाग pnpm कडे पाठवतो. त्यामुळे त्याला add @scope/dsh-plugin-example सारखे arguments आवश्यक असतात.

FAQ

DeepSeek Harness ला कोणती Node.js आवृत्ती आवश्यक आहे?

Repository च्या root package.json मध्ये ^22.19.0 || >=24.0.0 घोषित केले आहे. Repository ची आवृत्ती 0.2.1-alpha.1 असताना, 6 October 2026 रोजी हे वाचले गेले. त्यामुळे 22 line मधील Node 22.19.0 किंवा त्यानंतरची आवृत्ती, किंवा Node 24 आणि त्यानंतरच्या आवृत्त्या आवश्यक आहेत. Node 20 कार्य करणार नाही. प्रकाशित npm package मध्ये स्वतःचे engines field नाही. त्यामुळे npm तुम्हाला कधीही warning दाखवत नाही किंवा install रोखत नाही. त्याऐवजी failure runtime वर दिसते. प्रथम node -v तपासा. Node 24 हा तरीही चांगला पर्याय आहे, कारण त्यामध्ये npm 11 समाविष्ट आहे आणि त्यामुळे npx version reuse ची समस्या दूर होते.

Cached आवृत्तीऐवजी नवीनतम dsh वापरण्यासाठी npx ला कसे भाग पाडावे?

npm 11.2.0 आणि त्यानंतरच्या आवृत्त्यांमध्ये, npx @deepseek-ai/dsh प्रत्येक run वेळी bare package name साठी registry पुन्हा तपासते. प्रत्येक Node 22 release सोबत येणाऱ्या npm 10 मध्ये असे होत नाही. npm 11 वर npm cache npx rm --force वापरून npx cache साफ करा किंवा npm 10 वर rm -rf "$(npm config get cache)/_npx" वापरून तो folder हटवा. त्यानंतर npx @deepseek-ai/dsh --version वापरून पडताळा. लक्षात ठेवा की npm cache clean --force वेगळी directory साफ करते आणि ही समस्या दूर करणार नाही.

@deepseek-ai/dsh@^0.1.0 install करताना failure का येते?

npm ETARGET error code आणि No matching version found for @deepseek-ai/dsh@^0.1.0. ही line परत करते. प्रत्येक published build हा 0.2.0-rc.2 किंवा 0.2.1-alpha.1 यांसारखा prerelease आहे. Range मध्ये prerelease version चे नाव दिलेले नसल्यास semver range अशा versions शी जुळत नाही. Suffix सहित exact version string install करा. कोणत्या versions उपलब्ध आहेत हे पाहण्यासाठी npm view @deepseek-ai/dsh versions --json चालवा, कारण sequence मध्ये gaps आहेत आणि काही builds कधीही publish झालेले नाहीत.

dsh global install करावे की npx द्वारे चालवावे?

पहिल्यांदा पाहणी करण्यासाठी npx योग्य आहे, कारण cache directory व्यतिरिक्त काहीही कायम ठेवले जात नाही. काम सुरू ठेवणे आवश्यक असल्यास npm install -g @deepseek-ai/dsh@0.1.0-rc.7 सारखा pinned global install योग्य आहे, कारण तुम्ही version बदलल्याशिवाय ती आवृत्ती बदलत नाही. Global install नंतर dsh command सापडत नसेल, तर npm ची global bin directory तुमच्या PATH मध्ये नाही. npm prefix -g ती कोणत्या root अंतर्गत आहे ते दाखवते.

DeepSeek Harness वर आधारित काम सुरू करण्याइतके ते स्थिर आहे का?

अद्याप नाही, असे त्याच्या स्वतःच्या वर्णनावरून दिसते. README नुसार हा project developer preview मध्ये आहे, त्यावर वेगाने काम सुरू आहे आणि compatibility-breaking changes होणार आहेत. Release candidates 0.1.0-rc.6 आणि 0.1.0-rc.7 August 2026 मध्ये चार दिवसांच्या अंतराने publish झाले. तसेच 0.2.0-rc.1 आणि 0.2.0-rc.2 September 2026 मध्ये एक दिवसाच्या अंतराने publish झाले. Exact version pin करा आणि कोणत्याही guide ऐवजी त्या pinned build मधील --help वाचा. तुमच्या स्वतःच्या notes ला date द्या, म्हणजे त्या किती जुन्या झाल्या आहेत हे समजू शकेल.