Release Cadence

[arthurian]

Hi everyone! 👋

First, I want to express appreciation for this fantastic project. My team and I rely on it heavily, and we've also been happy to contribute back where we can.

As active users who can only deploy tagged releases, we've been eager to get our hands on the latest features and bug fixes as they're merged. To better understand the project's release cycle, I recently pulled some data from the GitHub releases and I noticed that the time between tagged releases appears to be increasing.

• 2023 average: ~9 days between releases
• 2024 average: ~22 days between releases
• 2025 average: ~38 days between releases

To make this clearer, I created a chart that visualizes the trend:

From our perspective as users, this lengthening cycle makes it challenging to test and adopt new improvements. It also means the feedback loop for our own contributions increases, as they wait in the main branch for a longer period before a tagged release. A predictable and more frequent cycle would be a huge help for downstream users like us.

I'm curious about the community's thoughts on this trend. Are there specific challenges making releases more complex? Would there be interest in exploring approaches like:

• Time-based release schedules (e.g., bi-weekly or monthly)
• Automated release processes (e.g. like LiteLLM)
• Pre-release tags (RC/beta) published more regularly for early adopters

Thanks and looking forward to the conversation!

[jona7o]

I think this awesome project has grown so fast that it is not that easy to fulfill a fixed release cycle. We build our own nightly builds from the main branch to try out new features before they get released. Most of the time these builds are stable and we can use the version for our devs.

[Lucas-almma]

Arthur brings a few valid points. The project is growing in complexity, and this trend is expected to continue. Your solution, Tobias, is a good one, but at some point, the organization around the project will need to grow to accommodate a more complex platform. At some point, feature creep can become an issue as well. For example, the admin panel is taking a major reworking of functionalities. It is natural for successful open-source repos to experience these challenges. I worked on a lot of them, and it depends on the vision of the project. I whole hartedly agree with every AI for everyone, but we need to support Danny when he allows and he wants us to contribute to keep this going. ᐧ

…

On Wed, Jul 16, 2025 at 10:47 PM Tobias Jonas ***@***.***> wrote: I think this awesome project has grown so fast that it is not that easy to fulfill a fixed release cycle. We build our own nightly builds from the main branch to try out new features before they get released. Most of the time these builds are all stable. — Reply to this email directly, view it on GitHub <#8499 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BGFKMSVQDJTQOEX2VB26A4T3I2255AVCNFSM6AAAAACBV6NPLGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGNZYGIZTSNQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[danny-avila]

The goal is to have more frequent releases and shorter release windows. Some of the longer delays have been an outcome of really big and ambitious changes, that needed more time to test/iterate on before a stable checkpoint. I think we are averaging around 100 commits between releases and would like to trim that down to 25-50 range.

In any case, v0.7.9 is slated to be done this weekend, to be available on Monday 7/21.

[arthurian]

That makes a lot of sense in terms of ambitious/complex changes requiring more commits. I wonder if it might be worth considering more frequent release candidates (i.e. -rc1, -rc2, -rc3, -rc4, ... along the path to a stable checkpoint. That would provide a path for downstream folks to test out the state of things at defined points and also provide a sense of progression toward a stable release. That wouldn't preclude anyone from sticking with the latest stable checkpoint or running the bleeding edge, but would provide a middle ground.