[Feature]: Define Desktop updater behavior across release channels
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
Start by reading .github/workflows/nightly-artifacts.yml and tracing the Desktop updater configuration and version comparison it feeds. Evaluate the proposed channel policies and document the selected behavior, including visibility and channel switching rules. Done means builds do not offer another channel's release solely due to SemVer ordering, including the stated Nightly versus stable example.
由索引模型根据 Issue 内容生成。
描述
Problem / opportunity
The Nightly desktop build is compiled as the nightly channel, but the current Nightly artifact workflow points its Tauri updater endpoints at the stable latest-v1.json feed because a Nightly updater feed is not published yet. As a result, a Nightly install can offer stable 1.0.6 as an update over 1.0.6-nightly.20261019, even though the Nightly build comes from a commit 128 commits ahead of v1.0.6. Comparing versions across channels makes the older stable code appear newer and can prompt an unintended cross-channel downgrade.
Proposed behavior
Please define the Desktop updater's release-channel policy and make feed selection and version comparison follow it. Possible designs to evaluate:
- All-channel build: let users choose stable, beta, or nightly updates, with explicit channel-aware version ordering and clear behavior when switching channels.
- Stable-only build: check only stable releases and never present beta or Nightly builds as updates.
- Nightly-only build: check only the Nightly feed, so a stable release cannot be offered as an update to a newer Nightly build.
The chosen behavior should make the active channel visible and avoid treating a release from another channel as a newer update solely because of SemVer ordering.
Product surface
Cross-cutting
Details, examples, or constraints
For example, on 1.0.6-nightly.20261019, the updater should not offer stable 1.0.6 as a newer build when its source commit is older. If channel switching is supported, make the switch explicit and define whether moving between channels is an update, downgrade, or reinstall.
- 主要语言
- Rust
- 星标
- 2.3k
- 派生
- 236
- 平均合并
- 6 小时 51 分钟
- 30 天内合并 PR
- 253
环境准备
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
GCWing/OpenBitFun 的其他 Issue
-
[Feature]: 模型服务表单缺少「图像生成」分类入口 —— 后端已支持 default_models.image_generation可能已有人在做 @skyfireitdiy 于 5 天前认领。 未关闭
难度 2/5 半天 新手友好度 74/100
GCWing/OpenBitFun#3279 · 1 个 reaction ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 72/100
GCWing/OpenBitFun#2363 ·
维护者通常 1 天内回复
-
question
难度 1/5 1 小时以内 新手友好度 78/100
GCWing/OpenBitFun#2340 ·
维护者通常 1 天内回复
-
[Bug]: 日志等级选择 Off 时配置校验拒绝该值可能已有人在做 @Raing5Days 于 1 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 35/100
GCWing/OpenBitFun#3483 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 28/100
GCWing/OpenBitFun#3482 · 1 条评论 ·
维护者通常 1 天内回复
查看 GCWing/OpenBitFun 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 76/100
longbridge/gpui-kit#3620 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 69/100
mongodb/kingfisher#564 ·
维护者通常 1 天内回复
-
bug qq-feedback
难度 2/5 1-3 小时 新手友好度 62/100
维护者通常 1 天内回复
-
corro-client drops the last byte of a response line that has no trailing newline可能已有人在做 @RaphaelFakhri 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 88/100
-
proxy: include denial_category in the "proxy request denied" log line可能已有人在做 @sreyas-endor 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 77/100
维护者通常 1 天内回复