Looking into a 0.53.0 release today. Some needed fixes went in that we'd like to get out.

https://github.com/All-Hands-AI/OpenHands/pull/10314 0.53.0 🙏

https://github.com/All-Hands-AI/OpenHands/pull/10465 0.54.0 release 🙏

https://github.com/All-Hands-AI/OpenHands/releases/tag/0.57.0 0.57.0 release ⚡

@better-park-34863 could i get 👀 on this release PR: https://github.com/All-Hands-AI/OpenHands/pull/11317 I've made two changes • added manual dispatch to cli pypi as well • fixed the token pypi token ref for CLI package to be

PYPI_TOKEN_OPENHANDS

Since we've already tagged a commit with

1.0.0-cli

and only the pypi package publishing failed, i'm adding the manual dispatch so we can release the pypi package without having to re-tag Will need to merge this PR into main to do the manual dispatch

https://github.com/All-Hands-AI/OpenHands/pull/11349 - performing patch release for V1 CLI off latest main cc @better-park-34863

It seems that due to some recent change, I can no longer use openhands-ai pypi library from an unreleased git commit. In the past I was able to do this:

pip install git+<https://github.com/All-Hands-AI/OpenHands.git@471d272c7c5d258fb5ce213b95e818772f304cac>
python -m openhands.core.main --task "print hello world"

but now I get this runtime error:

File "/opt/openhands-venv/lib/python3.13/site-packages/openhands/core/main.py", line 383, in <module>
    args = parse_arguments()
  File "/opt/openhands-venv/lib/python3.13/site-packages/openhands/core/config/utils.py", line 787, in parse_arguments
    from openhands import get_version
ImportError: cannot import name 'get_version' from 'openhands' (/opt/openhands-venv/lib/python3.13/site-packages/openhands/__init__.py)

https://github.com/All-Hands-AI/OpenHands/pull/11448 - patch release for cli cc @chilly-france-44439 could i get a 👀 for the PR

Do we have a release for this week 0.60.0 @better-park-34863 [planning community call tomorrow for first time contributors, etc] Will the 1.0.3-cli be live tomorrow @quick-window-91705 ty

https://github.com/OpenHands/OpenHands/pull/11574 - could i get a 👀 for this release pr

https://github.com/OpenHands/OpenHands/pull/11598 - patch release for cli

has renamed the channel from "eng-release" to "dev-release"

https://github.com/OpenHands/OpenHands/pull/11672 - ive made a cli release could i get a 👀 on this pr

Could i get a 👀 for this cli release PR: https://github.com/OpenHands/OpenHands/pull/11712

https://github.com/OpenHands/OpenHands-CLI/pull/138 - release PR for CLI Would be great if someone is willing to QA this and give me a green light

https://github.com/OpenHands/OpenHands-CLI/pull/165 - cli release cc @chilly-france-44439

https://github.com/OpenHands/OpenHands-CLI/pull/195 - CLI release 🚀

https://github.com/OpenHands/OpenHands-CLI/pull/229 - CLI release PR, need a 👀

https://github.com/OpenHands/OpenHands-CLI/pull/262 - cli release PR, need a 👀

Local GUI release 🙏 https://github.com/OpenHands/docs/pull/221 https://github.com/OpenHands/OpenHands/pull/12212

https://github.com/OpenHands/OpenHands-CLI/pull/281 - CLI release

has renamed the channel from "dev-release" to "proj-release"

set the channel topic: For coordinating on OpenHands releases.

Could we please consider the first step here?

1. Move the GUI components from OpenHands/OpenHands to OpenHands/OpenHands-Web, delete related code from the main OpenHands repo, update the README to note that we are migrating repo structure, and cut at least one OSS+SaaS release to make sure our infra is ready for this repo structure.

2. Migrate all GitHub issues/PR to OpenHands/OpenHands-Web

3. Then merge OpenHands/software-agent-sdk with OpenHands/OpenHands (using merge unrelated histories to preserve contributors & commits), and move all issues/PRs

4. We will archive the

OpenHands/software-agent-sdk

repo and point it to

OpenHands/OpenHands

for future references?

Step 1 really means to make the Web repo and cut a release from there. It should be the same thing and work just the same, I think? And if not, we'll find out? cc: @quiet-night-61895 @better-park-34863 @wooden-umbrella-84098 If there are blockers, could we maybe bring them out to address them?

How close are we to

openhands

repo release, @better-park-34863? ty

About release - 🔧 PR for review: Fix stale Docker image tags + add version consistency CI + skill for ship-release/bump-commit https://github.com/OpenHands/OpenHands/pull/13315 While investigating our release process (for my own development PR), I found that Docker image tags in 4 files have been stuck at

1.2

since the 1.2.0 release — the 1.3.0 and 1.4.0 releases only bumped the 3 core version files (

pyproject.toml

,

package.json

,

package-lock.json

) but missed updating the image references in

Development.md

,

containers/dev/compose.yml

,

docker-compose.yml

, and the Kubernetes README. This PR: 1. Fixes the stale tags — updates all 4 files to match the current

1.4.0

/ SDK

1.12.0

versions 2. Adds a

check-version-consistency.yml

CI workflow — runs on every PR to validate that version numbers and Docker image tags are consistent across all 7 files, so this can't silently drift again 3. Adds a

ship-release

skill — documents the full release checklist (which files to change, in what order) and how to pin SDK packages to unreleased git commits for testing Would appreciate a review when you get a chance 🙏

Has a local GUI release been made anytime recently?

The platform team has been working on some release and deployment process improvements. To make our applications more serviceable, we would like to create a shared release process that: 1. Automatically generates a changelog, so that it is easy to understand what changes are included in a release 2. Creates SemVer tags on each release, so that it is easy to locate the code included in a release and compare two different versions. 3. Is as consistent as is reasonably possible across our projects 4. Has no key person dependencies a. In other words, it should be easy enough to follow that any maintainer could cut a release, and releases shouldn't be blocked by the absence of a single person. I've put together this example repository which demonstrates a simple release process built with `release-please`: https://github.com/OpenHands/release-please-demo. The readme has a detailed walkthrough. It's very similar to the pipeline already implemented in software-agent-sdk, but with some additional automation. I'd like to get some feedback on this process before generalizing it so that we can share it across many repos, and then begin working on propagating it everywhere. Something the platform team already discussed is that for some of our projects like OpenHands Enterprise, we create release branches before every release so that we have some time to perform manual validation without picking up additional changes from

main

. I've added a section on how that would work to the readme, but would like to encourage releasing from

main

as the default. I think the extra complexity it introduces will discourage individuals from cutting a release, which ultimately harms goal #4 from above.

Hey @able-napkin-92802, I was looking into the release-actions repository: https://github.com/OpenHands/release-actions One thing that could be interesting for our release process, especially since we have tests that should only run during a release, would be the following workflow: • The chore(main) PR is initially created as a draft. • When someone marks it as ready for review (because they want to cut a release), we send a message to the corresponding Slack channel and trigger the "release" tests. This way, everyone is notified when a release is happening, and we can ensure that the release tests have actually run. WDYT? These features aren't implemented in the action yet, but they should be relatively easy to add. cc @chilly-france-44439 @calm-artist-7206

github.com/OpenHands/software-agent-sdk/pull/4027 Adds OpenHands/automation to version-bump-prs.yml, so it gets an automatic fix: bump SDK to X.Y.Z