Hey @modern-fireman-99755: it looks like you started incorporating the release-please workflow here but stopped halfway through? Maybe we could resume this work, since we use it on other repos? github.com/OpenHands/software-agent-sdk/pull/3939 If you don’t mind I’ll add a ticket for this.

yes... actually I had also a PR for the release action here. So I should just check on a private/personal repo if it works as intended. But should be fine.

Cool, thanks!

Just to note, I would like us to keep the release PR tests. We just started adding security scan tests, like “between the previous release and this release PR, did anything change on dependencies that no human appears to have seen?”

Hey @calm-artist-7206 @able-napkin-92802 as discussed in the above PR. I created a test repo to test the behaviour of the frozen-release-process: github.com/OpenHands/freeze-on-ready-test It seems to work fine. You can also play with that and give me a feedback if you like or not. The release process is: 1. Land work — PR to main with a Conventional Commit title (feat: / fix:), squash-merge. 2. release-please opens a draft chore(main): release X.Y.Z on main. Never merge this one. It's a preview of the next release, permanently in draft. 3. Cut the release — mark that draft ready for review. It freezes release/X.Y at the PR's base commit and returns itself to draft. Anything merged to main after this point is excluded. 4. release-please opens the real PR — chore(release/X.Y): release X.Y.Z, based on release/X.Y. Mark that one ready → it gets release: ready + other labels, Slack fires, tests dispatch. Soak it. 5. Merge it → tags vX.Y.Z and publishes the release. 6. Merge release/X.Y back into main → advances main's version; the draft from step 2 recycles to the next version. Repeat from 1. The two rules that matter - Only ever merge a PR whose base is release/** — plus the step-6 merge-back. - A PR based on main is never a release. Merging it publishes from main's moving tip, which is how you got the failed run and a v0.5.0 that didn't match what you soaked. This is the best I could do using the please-release-action and at the same time having all the tests we have in the sdk.

I think the flow makes sense to me, and I appreciate the extra validation. I dropped an approval on the release-actions PR!

I'm sorry, I haven’t got to review the latest changes. 🙏 I’m mostly concerned about the understanding of everyone who makes releases. I wonder, it would be nice to either, or both: • explain to the agent in the

skill.md

(

prepare-release

or

sdk-release

skill?) what it should do, and nudge it heavily to tell its human every single time a release PR is involved (so that it’s clear to people what to do and specially what not to do) • maybe we can make a self-contained HTML with the guidelines, sort of visually, easy to grasp?

Definitely agree with @calm-artist-7206 there though. Anything we can do to help devs (and agents) understand what process needs to be followed to prepare a release will be valuable.

My point was more: the release process makes it sense? Are we doing all the steps we need to release the sdk?

Cross linking for your attention Vasco, sorry just so we know we can do something similar with the sdk in canvas repo https://openhands-ai.slack.com/archives/C06QT0AGY4W/p1785001180953459?thread_ts=1784998950.334959&channel=C06QT0AGY4W&message_ts=1785001180.953459