Extract Common Logic into Public GitHub Actions

[jzheaux]

There are a number of tasks that are likely generic enough to merit extracting from this project and publishing in separate GitHub Actions projects so that other teams can take advantage of them:

• Extract Logic for Computing Versions into a Separate GitHub Action #81
• Extract Login for Updating Learn Page #82
• open-milestone - An action that opens the next milestone(s) for the given generation (or none if the generation is no longer supported)
• close-milestone - An action that closes a milestone, specifically the current one being released
• publish-release-notes - An action that publishes the release notes for a given milestone
• announce-on-gchat - An action that announces a completed release or one that it being planned

Also, some that do not yet exist that are worth considering:

• draft-release-blog - An action that publishes a PR with a draft blog post for the current release
• convert-to-commercial - An action that moves a branch from a project to its commercial counterpart once it is out of OSS support

[artembilan]

I can share what I have so far:

1. Current version: https://github.com/spring-io/spring-github-workflows/blob/main/.github/workflows/spring-find-release-version.yml
2. Update learn page: https://github.com/spring-io/spring-github-workflows/blob/main/.github/actions/spring-website-project-version-update/action.yml
3. Close milestone is a part of finalize release: https://github.com/spring-io/spring-github-workflows/blob/main/.github/workflows/spring-finalize-release.yml#L103
4. Release notes are also there: https://github.com/spring-io/spring-github-workflows/blob/main/.github/workflows/spring-finalize-release.yml#L91-L101
5. Announce is the last step: https://github.com/spring-io/spring-github-workflows/blob/main/.github/workflows/spring-finalize-release.yml#L123

[rwinch]

Does it make sense to split this list into sub issues so that it can be discussed more granularly and checked off as it is done?

A few items I'd like to see:

• For the blog post, I'd also like it to publish the blog automatically once all of the releases for a given date are done using a format similar to https://spring.io/blog/2025/11/17/spring-security-releases
• The blog post draft could pick up tickets with a particular label(s) that would be included as highlights
• The blog post draft would have a section that could contain manual changes
• I'd like open milestone to be able to open two versions for each generation at a time. This allows easily moving issues to the next patch release
• I'd like to automate creating a "Release" ticket on each milestone. This could be a way of blocking the release so it isn't automatically released on accident.
• Later on, the "Release" ticket might even have a checklist of sub tasks to do and provide updates as to where we are at. The other automation would potentially be able to close those tickets as it pushes changes.

[artembilan]

That might be a bit overhead, but how about regarding open-milestone to create (and potentially schedule) all the milestones at once for that generation until its OSS support is over? I mean we usually have maintenance milestones every single month, so that is predictable how many and when. Not clear, though, what would trigger such a population...

[jzheaux]

This is great, @artembilan, thank you for the links, they will be a big help so I have more than one set of projects' usage to go off of.

[rwinch]

Perhaps we can allow limitting how many milestones are scheduled per generation? I don't like having that many milestones in the drop down menus when I'm interacting with the UI.

[artembilan]

I don't like having that many milestones in the drop down menus

Right. So, then schedule just next one after release should be enough. Taking into account OSS support, of course.

[rwinch]

An action that figures out the oss and commercial timelines based upon a given generation is likely another valuable action. Making the input for generation flexible to support an input of 1.2.x (the branch), v1.2.3 (a version from a tag) or 1.2.3 / 1.2.3-SNAPSHOT / 1.2.3-M1 / 1.2.3-RC1 (version from the build) would be useful too.