mirror of
https://github.com/go-gitea/gitea.git
synced 2026-10-10 17:58:16 +00:00
43fedd662a
Automate release tagging as proposed in https://github.com/go-gitea/gitea/pull/39544#issuecomment-5955939142, part of https://github.com/go-gitea/gitea/issues/39550. A maintainer selects a release branch and version in the `release-create-tag` workflow. After approval through the `release-signing` environment, it pushes a GPG-signed tag. The tag starts the existing release build, which generates GitHub release notes with git-cliff from commits since the previous release, skipping `chore` and `ci` commits. `CHANGELOG.md` and release-candidate releases are removed. The workflow reuses the existing `GPGSIGN_KEY`, `GPGSIGN_PASSPHRASE`, and `RELEASE_TOKEN` repository secrets. Closes https://github.com/go-gitea/gitea/issues/39550 --------- Co-authored-by: bircni <bircni@users.noreply.github.com> Co-authored-by: silverwind <me@silverwind.io>
100 lines
4.4 KiB
Markdown
100 lines
4.4 KiB
Markdown
# Release management
|
|
|
|
This document describes the release cycle, backports, versioning, and the release manager checklist. For everyday contribution workflow, see [CONTRIBUTING.md](../CONTRIBUTING.md).
|
|
|
|
## Backports and Frontports
|
|
|
|
### What is backported?
|
|
|
|
We backport PRs given the following circumstances:
|
|
|
|
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
|
|
|
|
### How to backport?
|
|
|
|
In the past, it was necessary to manually backport your PRs. \
|
|
Now, that's not a requirement anymore as our [backport bot](https://github.com/GiteaBot) tries to create backports automatically once the PR is merged when the PR
|
|
|
|
- does not have the label `backport/manual`
|
|
- has the label `backport/<version>`
|
|
|
|
The `backport/manual` label signifies either that you want to backport the change yourself, or that there were conflicts when backporting, thus you **must** do it yourself.
|
|
|
|
### Format of backport PRs
|
|
|
|
The title of backport PRs should be
|
|
|
|
```
|
|
<original PR title> (#<original pr number>)
|
|
```
|
|
|
|
The first two lines of the summary of the backporting PR should be
|
|
|
|
```
|
|
Backport #<original pr number>
|
|
|
|
```
|
|
|
|
with the rest of the summary and labels matching the original PR.
|
|
|
|
### Frontports
|
|
|
|
Frontports behave exactly as described above for backports.
|
|
|
|
## Release Cycle
|
|
|
|
We use a release schedule so work, stabilization, and releases stay predictable.
|
|
|
|
### Cadence
|
|
|
|
- Aim for a major release about every three or four months.
|
|
- *Starting with v1.26 the release cycle will be more predictable and follow a more regular schedule.*
|
|
|
|
### Release schedule
|
|
|
|
We will try to publish a new major version every three months:
|
|
|
|
- v1.26.0 in April 2026
|
|
- v1.27.0 in June 2026
|
|
- v1.28.0 in September 2026
|
|
- v1.29.0 in December 2026
|
|
|
|
### 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.
|
|
|
|
### End of life (EOL)
|
|
|
|
We support per standard the last major release. For example, if the latest release is v1.26, we support v1.26 and v1.25, but not v1.24 anymore. We will only publish security fixes for the last major release, so if you are using an older release, please upgrade to a supported release as soon as possible.
|
|
Also we always try to support the latest on main branch, so if you are using the latest on main, you should be fine.
|
|
|
|
## Versions
|
|
|
|
Gitea has the `main` branch as a tip branch and has version branches
|
|
such as `release/v1.19`. `release/v1.19` is a release branch and we will
|
|
tag `v1.19.0` for binary download. If `v1.19.0` has bugs, we will accept
|
|
pull requests on the `release/v1.19` branch and publish a `v1.19.1` tag,
|
|
after bringing the bug fix also to the main branch.
|
|
|
|
Since the `main` branch is a tip version, if you wish to use Gitea
|
|
in production, please download the latest release tag version. All the
|
|
branches will be protected via GitHub, all the PRs to every branch must
|
|
be reviewed by two maintainers and must pass the automatic tests.
|
|
|
|
## Releasing Gitea
|
|
|
|
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:
|
|
- 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`
|