[FEATURE]:Stable Branch Release

[pi314ever]

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Hello @thdxr , thank you for the amazing work so far bringing such a feature
rich project. I have been enjoying using this project for standardizing my AI
agent usage. However, I have a couple of concerns about the current release
patterns.

From passively observing the releases over the past couple months, I have
noticed some issues with how releases are pushed out. As noted in several
issues (#214, #4206, #4114, #13177), the release cycle has been extremely fast,
with a majority of days releasing over 1 patch per day. This has caused
stability issues (#14338, #13137, #14264, etc.) that disrupt productive work
with opencode and is degrading the sentiment towards this project. I understand
the need to ship features fast, but this should not interfere with the users
who just want to get work done.

As previously suggested in #13177 and #214, I am urging the consideration of a
stable release cycle. I will attempt to propose something more actionable and
help build the argument for a stable release cycle.

Current issues with release cycle cadence:

• There are already multiple previous issues on bugs with release black screen only on desktop App. working well on TUI #14338, After updating the Windows desktop version today, I found an error #13137, Updating to 1.2.x hangs on sql migration #14264, etc.
• Repositories like nixpkgs are unable to keep up with current release cycle Too many releases, which version should be packaged? #4114
• Unreliable bug tracking with needing to retest every single new release
• Poor sentiment/user confidence in each release

Proposal

The current release cycle can be renamed/re-tagged as nightly builds (1.2.8,
1.2.9 -> 1.2.8-nightly.20260220, 1.2.8-nightly.20260221, assuming we are using
1.2.8 as latest stable commit). Each one of these releases will be tagged as
stable or unstable (will expand in a later section). The stable channel is then
derived in a 2 week cycle via the latest stable nightly release. An additional
beta channel can be added to bridge the time gap between monitoring the nightly
builds and official stable version release. A timeline of how this may work is
show below:

                 |<-------------- 1 week --------------->|<------------------ 2 weeks ------------------>|<---------- ...
Stability Window |                 1.2.9                 |                    1.2.10                     |            ...
Current          | 1.2.8 | 1.2.9 | ... | 1.2.15 | 1.2.16 | ... | 1.2.24 | ... | 1.2.31 | 1.2.32 | 1.2.33 |     ...      |
Proposed Nightly |   o   |   x   | ... |    o   |    x   | ... |    o   | ... |    o   |    x   |    o   |     ...      |
Proposed Beta    |---------------------------------------|  1.2.8-beta  |--------------------------------|  1.2.9-beta  |
Proposed Stable  |                         1.2.8                        |           1.2.9 (1.2.15 previously)           |
                 |<---------------------- 2 weeks --------------------->|<------------------ 2 weeks ------------------>|

Some benefits of this model include:

• More reliable auto-updates for beta/stable branch
• Keep bleeding edge channel for those who want the latest features/fixes
• Increase user trust on release model

Other Notes

• A specific setting on which channel updates are following (nightly, beta, stable) needs to be configurable.
• Changelog automation should be straightforward with the pipeline that already exists
• There should not be much more usage in release assets, as these channels can be implemented via release tags.

---

I am open to discussion and potentially contributing to this project if help is needed.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Could releases be more stable? #13177: "Could releases be more stable?" - Open issue asking about stable/beta release channels, directly covering the same request
• [FEATURE]: Better release cycles #4206: "[FEATURE]: Better release cycles" - Open feature request for structured release cycles (bundled releases, predictable schedule)
• [FEATURE]: Stable Branch Release #14357: "[FEATURE]: Stable Branch Release" - Closed issue with identical title and content (appears to be a prior submission of this same request)

Since #13177 and #4206 are already open and cover the same ground, consider adding your proposal details as a comment on one of those existing issues rather than opening a new one. The maintainers may close this as a duplicate.

[JohnDuncanScott]

I'd like to add to this that I've had to rollback a number of versions (to v1.1.65) because of the blank screen issue in macos desktop app (which is already logged elsewhere), which is totally unworkable. The releases are coming out so quickly, there's no way they're being regression tested properly. These are bugs that appear if you use the app for a few minutes and would be spotted by a human. There needs to be a release channel and a beta channel, with the default being the release channel when notifying people of updates. In its current state, there's no way I can recommend this for general use. Someone can install an unusable build literally the very next day. It's a fantastic project and I would love to make it my primary mode of work, but it needs to have stable, human tested, releases.