Release Cadence and Versioning
Gitea Enterprise follows a rolling release model for self-hosted and on-premises deployments. Customers with an active Gitea Enterprise subscription receive ongoing product updates, bug fixes, security updates, and access to Enterprise support.
How releases work
Section titled “How releases work”Gitea Enterprise is released on a predictable cadence so teams can plan upgrades for production environments. In addition to scheduled releases, we may publish out-of-band updates when necessary to address important security issues or urgent fixes.
Major versions do not follow a fixed three-month schedule. Release timing varies by release readiness and current planning, and each major version remains the current supported line until the next major version is released and becomes the recommended upgrade path.
What support includes
Section titled “What support includes”During an active subscription period, Gitea Enterprise support may include:
- access to current Enterprise releases
- bug fixes and maintenance updates
- security updates
- product guidance through Enterprise support channels
- upgrade guidance for supported deployment paths
The exact response model and service terms depend on the applicable subscription agreement.
Production upgrade guidance
Section titled “Production upgrade guidance”For production environments, we recommend validating new releases in a staging environment first and staying reasonably current with the recommended upgrade path so your deployment continues to receive the latest fixes and security improvements.
Lifecycle policy
Section titled “Lifecycle policy”Gitea Enterprise does not currently publish a public lifecycle matrix with separate end-of-life dates for every version in the style of products that maintain many public long-lived release branches. Instead, a major version remains current until the next major version is released and becomes the recommended upgrade path.
Instead, the public policy is based on the rolling release model and the active subscription period. If your procurement or operations process requires a more conservative rollout plan, please contact us at support@gitea.com or via the customers portal.
Recent and planned major releases
Section titled “Recent and planned major releases”The table below is intended to show the recent major release history and the current planning window for the next major release.
| Version | Status | Release timing | Notes |
|---|---|---|---|
| v26 | Planned | June 2026 | Planned timing is subject to change based on validation and security requirements |
| v25 | Current | February 2026 | Latest recommended major release |
| v24 | Previous | June 2025 | Previous major release |
| v23 | Previous | February 2025 | Previous major release |
| v22 | Previous | June 2024 | Previous major release |
Planned release timing should be treated as an expected window rather than a fixed public commitment. Update this section whenever a new major version is released or the next planning window changes.
Why is there no per-version EOL table?
Section titled “Why is there no per-version EOL table?”Gitea Enterprise currently follows a rolling release model rather than a broad set of public long-lived maintenance branches with separate end-of-life dates for each version. In general, a major version remains the current supported line until the next major version is released and becomes the recommended upgrade path.
If your procurement or operations process requires a more conservative rollout plan, please contact us at support@gitea.com or via the customers portal.
How does Gitea Enterprise differ from products that publish per-version EOL tables?
Section titled “How does Gitea Enterprise differ from products that publish per-version EOL tables?”Some self-hosted enterprise products publish a separate end-of-life date for each feature release and maintain multiple long-lived public release branches in parallel.
Gitea Enterprise currently follows a rolling release model instead. Customers with an active subscription receive ongoing product updates, bug fixes, security updates, and Enterprise support, and major version timing is communicated through the published recent and planned release schedule.
This model is designed for teams that prefer a continuously updated self-hosted platform and a predictable upgrade path, rather than a large matrix of long-lived public maintenance branches. For organizations that require a more conservative rollout approach, we recommend validating releases in staging first and contacting us to discuss the most suitable upgrade strategy for their environment.