BTW, do we have any plans on when we expect to rem...
# proj-sdk
c
BTW, do we have any plans on when we expect to remove all the V0 releated code in OpenHands repo? (cc @wooden-umbrella-84098 @purple-thailand-64770)
w
I believe there are still a lot of workflows using v0. E.g. I think GitHub comments trigger v0
😭 1
And the microagents UI still uses v0 (but I'd be in favor of removing that for now)
c
Do we have a target on when the full migration will be done? 👀
e
Some thoughts on retiring V0 APIs: • We have customers using REST V0 APIs, primarily in SaaS and Self-hosted • I'm not sure if we've documented ◦ REST v1 APIs ◦ Any migration tips from v0 to v1 • We should probably set a date in the future when we expect to remove v0 APIs (say, give user 30 days), publish that notification, and send an email to the newsletter with the EOL date
👍 1
➕ 1
nod 1
a
never? git is immutable
c
publish that notification, and send an email
Have we started this process? Sorry I ask, I believe it will be good to remove V0 code as soon as possible and/or move it out of the popular path (OpenHands/OpenHands). Because people are looking at the OpenHands repo and assuming that the code they see is the code of OpenHands, on LLM, Agent, etc., when it’s not (it’s V0 code in that repo). The relevant code is in V1 agent-SDK now. Example 1: people analyze V0 code and report what doesn’t work for Kimi and DeepSeek, and I worry this is probably due to the confusion - this code lives in the SDK now. Example 2: people adapted the GPT-5 specific “apply patch” tool to V0 code, just last week, when we have already adapted and merged
apply_patch
in SDK a while ago. Everyone is of course free to do that, but I do worry that, if unintended, it leads to duplicate work and time.
c
We still haven't turned the v1 for 100% of SaaS traffic and the Github resolver is not yet working yet for V1 -- But I definitely agree with Engel we should try to remove them sooner than later, maybe we can keep a "v1" branch that keep all the code to maintain backward compatibility for production and start to remove all legacy code from
main
?
nod 1
I guess we could get started by removing all the legacy runtimes / Conversation Manager that we no longer use / V0 APIs and stuff since irrc the last OSS release enables V1 in OSS docker command?
s
Yeah - we will be removing the V0 APIs - but slowly
w
At the very least we can put giant comments in the code for now
Joe is putting together an EOL plan
c
Comments in the code, though maybe not giant thinky spin https://github.com/OpenHands/OpenHands/pull/12165
s
Step 1 will most certainly be Deprecation - through comments, python decorators, and openapi.