Reimplement release creation workflow

[kwankyu]

Fixes the issue raised in sagemath/website#480 (comment)

I manually edited the release https://github.com/sagemath/sage/releases/tag/10.5 generated by an workflow implemented in sagemath/website#480 to correct the changelog https://github.com/sagemath/website/blob/master/src/changelogs/sage-10.5.txt, which is now in good shape. But see, for example, https://github.com/sagemath/sage/releases/tag/10.4 that contains all changes in betas and rcs.

This PR is for automatic generation of a release that contains only changes from the last release.

test:
https://github.com/kwankyu/sage/releases
https://github.com/kwankyu/sage/actions/runs/12485317339/job/34844199681

📝 Checklist

• The title is concise and informative.
• The description explains in detail what this PR is about.
• I have linked a relevant issue or discussion.
• I have created tests covering the changes.
• I have updated the documentation and checked the documentation preview.

⌛ Dependencies

[kwankyu]

I am investigating the issue raised in #39083 (comment)

[github-actions]

Documentation preview for this PR (built with commit 28ef753; changes) is ready! 🎉
This preview will update shortly after each push to this PR.

[tobiasdiez]

But see, for example, https://github.com/sagemath/sage/releases/tag/10.4 that contains all changes in betas and rcs.

From a user's perspective, is this not the most comfortable way to list the changes? If I'm on the latest stable 10.4 (like most "normal users") and upgrade to 10.5, I would like to see all the changes between those versions, or not?

[kwankyu]

@soham30rane You are correct. The release generation step of the workflow indeed needs to use both APIs as you said in #39083 (comment). It works well now.

[kwankyu]

But see, for example, https://github.com/sagemath/sage/releases/tag/10.4 that contains all changes in betas and rcs.

From a user's perspective, is this not the most comfortable way to list the changes? If I'm on the latest stable 10.4 (like most "normal users") and upgrade to 10.5, I would like to see all the changes between those versions, or not?

WIth the current workflow, in Releases, a change appears in a beta release first and then reappears in the list of the changes between two stable releases. With this PR, a change appears just once in a beta release between two stable releases. Well, yes, it gets a bit less comfortable. On the other hand, it gets a bit less confusing and compatible with the practice of https://groups.google.com/g/sage-release, and makes the workflow introduced in sagemath/website#480 behave correctly.

[tobiasdiez]

But see, for example, https://github.com/sagemath/sage/releases/tag/10.4 that contains all changes in betas and rcs.

From a user's perspective, is this not the most comfortable way to list the changes? If I'm on the latest stable 10.4 (like most "normal users") and upgrade to 10.5, I would like to see all the changes between those versions, or not?

WIth the current workflow, in Releases, a change appears in a beta release first and then reappears in the list of the changes between two stable releases. With this PR, a change appears just once in a beta release between two stable releases. Well, yes, it gets a bit less comfortable. On the other hand, it gets a bit less confusing and compatible with the practice of https://groups.google.com/g/sage-release, and makes the workflow introduced in sagemath/website#480 behave correctly.

Okay, makes sense.

[soham30rane]

Looks good overall !
I'm unsure about the token permissions, especially for the POST request to create the release. Does the GITHUB_TOKEN have sufficient scope for this?

[kwankyu]

The action softprops/action-gh-release@v already works without an elevated permission, perhaps because GITHUB_TOKEN has "read and write" permissions in the settings. I see no reason that the new workflow is different in that regard. It also works well in my test repo.

[soham30rane]

Okay Great! It seems good to go! Thank you

[kwankyu]

Thanks!