[FEATURE]:Stable Branch Release #14358

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.