ci(release): automate signed release tags and release notes (#39544) (#39622)

Backport #39544

Co-authored-by: bircni <bircni@icloud.com>
Co-authored-by: bircni <bircni@users.noreply.github.com>
Co-authored-by: silverwind <me@silverwind.io>

docs/release-management.md

@@ -8,10 +8,9 @@ This document describes the release cycle, backports, versioning, and the releas
 
 We backport PRs given the following circumstances:
 
-1. Feature freeze is active, but `<version>-rc0` has not been released yet. Here, we backport as much as possible. <!-- TODO: Is that our definition with the new backport bot? -->
-2. `rc0` has been released. Here, we only backport bug- and security-fixes, and small enhancements. Large PRs such as refactors are not backported anymore. <!-- TODO: Is that our definition with the new backport bot? -->
-3. We never backport new features.
-4. We never backport breaking changes except when
+1. We backport bug- and security-fixes and small enhancements. Large changes such as refactors are not backported.
+2. We never backport new features.
+3. We never backport breaking changes except when
     1. The breaking change has no effect on the vast majority of users
     2. The component triggering the breaking change is marked as experimental
 
@@ -53,7 +52,6 @@ We use a release schedule so work, stabilization, and releases stay predictable.
 ### Cadence
 
 - Aim for a major release about every three or four months.
-- Roughly two or three months of general development, then about one month of testing and polish called the **release freeze**.
 - *Starting with v1.26 the release cycle will be more predictable and follow a more regular schedule.*
 
 ### Release schedule
@@ -65,16 +63,6 @@ We will try to publish a new major version every three months:
 - v1.28.0 in September 2026
 - v1.29.0 in December 2026
 
-#### How is the release handled?
-- The release manager will tag the release candidate (e.g. `v1.26.0-rc0`) and publish it for testing in the **first week of the release month**.
-- If there are no major issues, the release manager will check with the other maintainers and then tag the final release (e.g. `v1.26.0`) in the **one or two weeks following the release candidate**.
-
-### Feature freeze
-
-- Merge feature PRs before the freeze when you can.
-- Feature PRs still open at the freeze move to the next milestone. Watch Discord for the freeze announcement.
-- During the freeze, a **release branch** takes fixes backported from `main`. Release candidates ship for testing; the final release for that line is maintained from that branch.
-
 ### Patch releases
 
 During a cycle we may ship patch releases for an older line. For example, if the latest release is v1.2, we can still publish v1.1.1 after v1.1.0.
@@ -99,17 +87,13 @@ be reviewed by two maintainers and must pass the automatic tests.
 
 ## Releasing Gitea
 
-- Let MAJOR, MINOR and PATCH be Major, Minor and Patch version numbers, PATCH should be rc1, rc2, 0, 1, ...... MAJOR.MINOR will be kept the same as milestones on github or gitea in future.
-- Before releasing, confirm all the version's milestone issues or PRs has been resolved. Then discuss the release on Discord channel #maintainers and get agreed with almost all the owners and mergers. Or you can declare the version and if nobody is against it in about several hours.
-- If this is a big version first you have to create PR for changelog on branch `main` with PRs with label `changelog` and after it has been merged do following steps:
-  - Create `-dev` tag as `git tag -s -F release.notes vMAJOR.MINOR.0-dev` and push the tag as `git push origin vMAJOR.MINOR.0-dev`.
-  - When CI has finished building tag then you have to create a new branch named `release/vMAJOR.MINOR`
-- If it is bugfix version create PR for changelog on branch `release/vMAJOR.MINOR` and wait till it is reviewed and merged.
-- Add a tag as `git tag -s -F release.notes vMAJOR.MINOR.PATCH`, release.notes file could be a temporary file to only include the changelog this version which you added to `CHANGELOG.md`.
-- And then push the tag as `git push origin vMAJOR.MINOR.$`. CI will automatically create a release and upload all the compiled binary. (But currently it doesn't add the release notes automatically. Maybe we should fix that.)
-- If needed send a frontport PR for the changelog to branch `main` and update the version in `docs/config.yaml` to refer to the new version.
-- Send PR to [blog repository](https://gitea.com/gitea/blog) announcing the release.
+Track each release using the [release issue template](https://github.com/go-gitea/gitea/issues/new?template=release.yaml).
+
+- Before releasing, confirm all the version's milestone issues or PRs have been resolved. Then discuss the release on Discord channel #maintainers and get agreed with almost all the owners and mergers. Or you can declare the version and if nobody is against it in about several hours.
+- When creating a release branch, tag its fork point on `main` as the next version's `-dev` tag, e.g. `v30.0.0-dev` for `release/v29`.
+- In the GitHub Actions tab, open the `release-create-tag` workflow, click "Run workflow", select the release branch and enter a version such as `28.0.1`. After maintainer approval, it pushes a signed tag and CI publishes the release with generated notes.
+- Optionally send a PR to the [blog repository](https://gitea.com/gitea/blog) announcing the release.
 - Verify all release assets were correctly published through CI on dl.gitea.com and GitHub releases. Once ACKed:
-  - bump the version of https://dl.gitea.com/gitea/version.json
+  - verify the automated update of https://dl.gitea.com/gitea/version.json, where applicable to the release line
   - merge the blog post PR
   - announce the release in discord `#announcements`