Skip to main content
Version: 24.7.0

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

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

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

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

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

The table below is intended to show the recent major release history and the current planning window for the next major release.

VersionStatusRelease timingNotes
v26PlannedJune 2026Planned timing is subject to change based on validation and security requirements
v25CurrentFebruary 2026Latest recommended major release
v24PreviousJune 2025Previous major release
v23PreviousFebruary 2025Previous major release
v22PreviousJune 2024Previous 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.

FAQ

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?

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.