Forgejo monthly update - March 2024

The monthly report is meant to provide a good overview of what has changed in Forgejo in the past month. If you would like to help, please get in touch in the chatroom or participate in the ongoing discussions.

Forgejo 7.0.0 release candidates are now available for testing at or by downloading OCI images (root / rootless) and binaries that are updated updated daily.

The 7.0.0+LTS-gitea-1.22.0 version is the first Long Term Support (LTS) release and will receive critical bug and security fixes until July 2025. It is an additional burden on Forgejo contributors and members of the release team. Individuals and organizations who need that kind of stability are kindly invited to contribute to this effort so it can be sustained in the long run.

New languages that got active translators and have reached a usable level of completion were added and are now visible to users: Bulgarian, Esperanto, Filipino and Slovenian.

New release management

Now that Forgejo forked its own way forward, it became necessary to define when and how releases are published.

Semantic versioning

The first Forgejo version to be published with its own release management will be 7.0.0+LTS-gitea-1.22.0 and the documentation was updated to explain the new numbering scheme.

Gitea API compatibility

Tools that are developed for the Gitea API will keep working with the new Forgejo numbering scheme. They typically make assertions on the release number to unlock new functionalities and that logic will not be impacted by a bump in the release number. The proprietary version of Gitea has a different numbering scheme (v21.X.Y, v22.X.Y) and is in a similar situation.

Forgejo 7.0 release candidates

The 7.0/forgejo branch was cut 30 March 2024 and the v8.0.0-dev tag set to the development branch. While the release-critical bugs are being fixed so that the version can be published, will keep being updated daily with a build of the latest commit, acting as a release candidate where anyone can safely try and break it. It can also be installed locally with:

Their name stays the same but they are replaced by a new build every day.

Forgejo 7.0 LTS

Now that Forgejo has given itself the mean to avoid most of the regressions that it suffered from in the past, it can provide support for releases during a longer period of time. The 7.0.0+LTS-gitea-1.22.0 version is the first Long Term Support (LTS) release and will receive critical bug and security fixes until July 2025.

Time based release schedule

The time based release schedule was established to publish a release every three months. Patch releases will be published more frequently, depending on the severity of the bug or security fixes they contain. The exact number of the release cannot be known in advance because it will be determined by the features and breaking changes it contains, as specified by the Semantic Versioning 2.0.0 specifications.

DateVersionRelease dateEnd Of Life
2024 Q17.0.0+LTS-gitea-1.22.017 April 202416 July 2025
2024 Q2X.Y.Z+gitea-A.B.C17 July 202416 October 2024
2024 Q3X.Y.Z+gitea-A.B.C16 October 202415 January 2025
2024 Q4X.Y.Z+gitea-A.B.C15 January 202516 April 2025


Notable improvements and bug fixes:

Read more in the pull requests.

Backport automation

When pull requests are merged, a workflow will automatically open a backport. If the backport/v1.21 label is found, it will target the Forgejo v1.21 branch. If there are no conflicts and tests pass, it can be merged right away and save valuable time.

As Forgejo 7.0 enters the release candidate stage of its life cycle a significant number of backports are expected during the first few weeks and such an automation will have even more of an impact.

Dependency Management

A dependency update detection cron job has been setup to automatically open pull request proposing updates when new versions of Go or JavaScript packages, OCI images and more are available. It finds the release notes, adds them to the pull request description and Forgejo contributors can then conveniently decide whether an upgrade is necessary. This recurring observations of Forgejo dependencies is fine tuned by a configuration file that, among other things, ensures there are at most five pull requests proposed at all times.

The weekly cherry-pick of commits from Gitea became a routine collectively managed by two Forgejo contributors. It is one of the improvements brought by the hard fork decision from last month. Rebasing was more involved and managed by a single person: an undesirable single point of failure. A tool was created to automate the most tedious and error prone tasks.

End to end tests

The end-to-end tests were entirely refactored for unification and simplicity. They cover the following areas:

They can now all be run by adding the run-end-to-end-test label to a pull request (see this example). Before the refactor, only Forgejo Actions tests were run.


New languages that got active translators and have reached a usable level of completion were added and are now visible to users: Bulgarian, Esperanto, Filipino and Slovenian.

New contributors were onboarded (1, 2) to the localization team.

The English source strings saw a lot of activity for unification and rewording. There were no notable conflicts with Gitea translations. There was one conflict caused by merged pull request in Forgejo that locked translations for about half of a day. Although Weblate owns all translated files and they are not to be modified in pull requests, there are exceptions. When mass modification can be automated, this can be done by a pull request and to save valuable translators’ time. But when it happens, care must be taken to avoid conflicts and the required steps were documented.

The upside of this incident was to show that resolving such conflicts is as simple as reverting the faulty commit and opening a new pull request. It is not the most efficient way to go about it, but it is simple.


The pull request to implement federated stars made progress. In the settings of a repository there is now a field allowing to define its federated repositories. Read more in the activity summary.

The federation implementation task list was updated.

Helm chart

The Forgejo helm chart had one major updates because of a major bump of the postgresql dependencies.



The Forgejo runner version 3.4.1 was published and supports for the artifacts@v4 protocol when used with the development version of Forgejo 7.0, as demonstrated by the end-to-end tests.

With the caveat that a forked version of the matching download and upload actions must be used because they both assume a GitHub environment. Chasing such features is high maintenance and casts a doubt on its long term viability. The Forgejo runner makes no promise of compatibility with GitHub and an alternative action with the same interface but implemented differently may be, for example, a more sustainable choice.




A discussion started in an attempt to find an answer and make Forgejo durable for the next 10 years.

A grant proposal was drafted to support the development of Forgejo.

An additional Request for Payment was sent to NLnet in the context of the ongoing grant and the funds will go to Codeberg.

We Forge

Forgejo is a community of people who contribute in an inclusive environment. We forge on an equal footing, by reporting a bug, voicing an idea in the chatroom or implementing a new feature. The following list of contributors is meant to reflect this diversity and acknowledge all contributions since the last monthly report was published. If you are missing, please ask for an update.

A minority of Forgejo contributors earn a living by implementing the roadmap co-created by the Forgejo community, see the sustainability repository for the details.