https://docs.all-hands.dev/ logo
Join Slack
Powered by
Hi <@U0733742FR8> and <@U093XHCH2D8>, we have this...
# proj-documentation
l
Hi @better-park-34863 and @gentle-apple-32922, we have this PR on a weekly changelog generator on the agent SDK repo (thanks @careful-needle-1740 for submitting it!): https://github.com/OpenHands/software-agent-sdk/pull/785 Let’s say we could create a changelog automatically: 1. when would it be most useful to do it (e.g. every version, every time Jamie sends out a newsletter) 2. what are the characteristics of a “good” changelog (e.g. cover major features, have good structure, are there any prime examples) Based on this, we can refine Tejas’s PR
👀 2
b
1. Every version release is the standard and makes the most sense, no? 2. a. Each entry should be user-facing changes that users may care about. Important bug fixes, major features, breaking changes b. Usually structured based on headers of breaking, added, fixed. This is my 2 cents.
c
Just a quick question here: are we thinking to make a changelog this way for each major project, SDK, CLI, Web? (maybe also Enterprise? Idk)
I actually have a couple of concerns on the user-facing requirement. The first is that it doesn't seem applicable for SDK, user-facing means there client developer-facing, which is probably or possibly everything
l
@better-park-34863 thanks! I guess we can use these as a template: https://github.com/OpenHands/OpenHands/releases/tag/1.0.0 @calm-artist-7206 I think currently for these sorts of automations we’re dogfooding them on the smaller (but still important) software-agent-sdk, and then will roll them out more widely if they work well. “user-facing” for the SDK indeed means “developer-using-the-SDK facing” (but not necessarily “developer-developing-the-SDK facing”)
c
developer-developing-the-SDK
Yes, I hear you, definitely, but I am not sure this distinction, or even missing it, leads to a bad consequence in this case. Maybe it's just me missing something? I admit I am much more concerned about the other side here, where we don't show some stuff that for a reason or another, could be interesting...
l
Actually on reflection, I think that maybe a manually triggered github action (just using our standard github action script) may be sufficient here.
Copy code
I would like to create a change log for all the changes from the most recent release up until now. Look at the change logs for the previous releases and try to follow a similar format, covering moderate to majorly important user-facing changes. The final changelog should be up put in markdown format so I can copy paste it into the release and edit.
g
For the newsletter, it is best o have the release available monday or at minimum first thing tuesday. i like to schedule a wednesday send out tuesday afternoon
l
@nutritious-balloon-65098 based on my suggestion above, let's create a 
/releasenotes
skill in the OpenHands/skills repo following the format of other skills, and open a draft pr
n
I'm on it! Graham Neubig can track my progress here.
Summary I've created the 
/releasenotes
skill in the OpenHands/skills repository and opened a draft PR. Checklist • ✅ Created 
/releasenotes
skill following the format of other skills (YAML frontmatter with triggers, structured instructions) • ✅ Based on your team's discussion about changelog requirements: ◦ Focuses on user-facing changes (features, bug fixes, breaking changes) ◦ Uses standard categories: Breaking, Added, Changed, Fixed, Deprecated, Removed, Security, Notes ◦ Follows the format of existing releases (like OpenHands 1.0.0) ◦ Outputs markdown ready for copy-paste into GitHub releases • ✅ Pushed to branch 
add-releasenotes-skill
• ✅ Opened draft PR Draft PR https://github.com/OpenHands/skills/pull/6 What the skill does When triggered with 
/releasenotes
, it will: 1. Identify the last release using git tags 2. Gather changes from commits and merged PRs 3. Categorize changes into standard sections 4. Filter for user-facing changes (excluding internal refactoring, CI changes, etc.) 5. Follow the repository's existing release format 6. Output markdown ready for copy-paste The skill is designed to be manually triggered (as you suggested) and produces output that can be edited before publishing. <sub>View full conversation</sub>
l
@nutritious-balloon-65098 wow, you went kinda crazy with the detail there. read the other skills in the repo and limit the verbosity to match other similarly simple skills
n
I'm on it! Graham Neubig can continue tracking my progress here.
Done! I've created a concise 
/releasenotes
skill and opened a draft PR. Checklist • ✅ Created 
/releasenotes
skill following the format of other simple skills in the repo • ✅ Simplified the skill to match the verbosity level of similar skills (17 lines vs original 97) • ✅ Pushed to branch 
add-releasenotes-skill
• ✅ Opened draft PR The skill (
skills/releasenotes.md
) A simple 17-line skill that: 1. Finds the most recent release tag 2. Gathers commits/PRs since that tag 3. Matches the repo's existing release format 4. Categorizes into Breaking Changes, Added, Changed, Fixed, Notes 5. Focuses on user-facing changes 6. Outputs markdown ready for copy-paste Draft PR: https://github.com/OpenHands/skills/pull/6 <sub>View full conversation</sub>
2 Views
Open in Slack
PreviousNext
Powered by