Plans for Gitea 1.24

[lunny]

Hi all,

Gitea v1.23.0-rc0 has been released.
We have created the release/v1.23 branch accompanied by the v1.24.0-dev tag and are now using main for 1.24 development.
As always, this issue is intended to show what you can expect from the next version.

Schedule

Gitea 1.24 is currently set to enter feature freeze on 2025-04-01 23:59 UTC, and released on 2025-04-25 23:59 UTC
This deadline is at the moment only a rough estimate and might change in the future.

Roadmap

Potential pull requests to be included in this release.

• Add a new section named development in issue view sidebar to interact with branch/pr #31899
• Sync issues, PRs, labels, milestones, comments from GitHub mirrors #20311
• Live removal of issue comments using htmx websocket #28958
• Add project workflow feature so users can define how to execute steps when project related events fired #30205
• Notes for Project-Board-Columns #29045
• Limit repo size #21820
• Add support for migrating GitLab comment reactions #29413
• Rewrite compare functions #32786
• Add file tree to file view page #32721
• Add project column choice option on issue sidebar #30617

Previous Plans

• Plans for Gitea 1.23 #30261
• Plans for Gitea 1.22 #27194
• Plans for Gitea 1.21 #25123
• Plans for Gitea 1.20 #23072
• Plans for Gitea 1.19 #21598
• Plans for Gitea v1.18 #20022
• Plan of Gitea v1.17 #18345
• Plan of Gitea v1.16 #16429
• Discussion of v1.15.x Roadmap #14477

⚠️ Important

This summary is for things you plan to implement yourself, not things you want (from other people).
Wishes and other off-topic comments will be hidden.

[delvh]

I'll start with my plan:

• Automating the release process as much as possible.
  My goal is that periodically (most likely every 4 months so that we have three releases per year) on a certain date, a release job runs that uses the current state of main, and releases it as is as the next full version. Our only remaining job will then be preparing the blog post in advance.

[marcellmars]

I plan to follow up on Enhancing Gitea OAuth2 Provider with Granular Scopes for Resource Access and address the access to resources if the scope public is present in the OAuth2/OIDC grant application.

The steps are:

• Open an issue to discuss how we want to process the public scope if the request targets "nested" resources, such as repositories under a user URL path. In cases where a list is returned, we will need to make decisions, such as whether to consolidate the process by always performing a database search query or traversing without it, etc. I will propose my preferred approach for implementing this.
• Implement the agreed-upon solution.

[RedCocoon]

Hopefully I can get Separation of Conversations and Issues, and Adding Conversation to Commits implemented.

Right now I still need some suggestions on how to make it better, and later on make the documentation for its API endpoint and whatnot.