Conversation
Co-authored-by: 若琳酱 <ruollin@outlook.com>
ac617a0 to
19d369e
Compare
|
我觉得我们还是需要讨论一下是否应当限制用户自由选择更新通道,FR 之前的限制逻辑出过很多稀奇古怪的问题 这里重申一下我之前的观点:限制测试通道用户回退到更早的正式版本是合理的,但是限制测试通道用户更新到下一个正式版本是不合理的 |
|
现在需要一个配置分离的PR 作为本 PR 的前置,不然这里没法合并 |
|
突然想起来,此处对 Action 的修改会不会导致和 Mirror 酱的冲突问题?现在 Mirror 酱会同步 Release 过去 |
不太了解 Mirror 酱那边的策略,如果能设置排除是否可以考虑下不同步特定 Release? |
可能得去问问,我晚点看看吧 |
是不是可以换成效果类似的CI构建,实现应该会简单一点 |
# Conflicts: # Plain Craft Launcher 2/Modules/ModSecret.vb # Plain Craft Launcher 2/Pages/PageSetup/PageSetupSystem.xaml # Plain Craft Launcher 2/Pages/PageSetup/PageSetupSystem.xaml.vb
ruattd
left a comment
There was a problem hiding this comment.
道理我都懂,但是为什么....只剩 13 行 changes 了...?
之前写的时候拿着整个仓库问了 Copilot,说是如果只是添加新的更新通道而不是新的更新源只需要在 没看错的话我记得 |
当了波丁真把疑似 IDE 瞎几把改的地方回退回去了,顺带把涉及到的文件过大的缩进改了下(
本 PR 实现了一个新的更新通道 开发版 / Dev,目的是方便高级用户第一时间体验最新的更改与 Bug 修复而无需等待下一个正式版 / Release 或测试版 / Beta 版本。
锁定逻辑等与 FR 基本一致,但因开发版不稳定的特性而对用户操作进行了二次确认。
并且为确保遇到严重问题的用户能够第一时间获得修复,通道强制更新(即“更新” 与 “或者更新”分别代表“确认” 与 “取消”,且均会触发更新流程)。~~这个不计划在程序本体中实现了,等 APIv3 的强制更新功能上线再说。需要 Actions 支持,每晚对过去 24 小时的更改进行编译并打包对应架构压缩包。整体流程与现有的正式版 / 测试版一致。以下是一个
updates-devx64.json示例:{ "assets": [ { "file_name": "PCL2_CE_Dev_x64.exe", "version": { "channel": "devx64", "name": "2.14.0-dev.g1a2b3c4", "code": 99920260201 }, "upd_time": "2026-02-01 00:00:00", "downloads": [ "https://github.com/PCL-Community/PCL2_CE_Server/raw/main/static/raw/{sha256}.zip", ], "patches": [], "sha256": "abc123...", "changelog": "Daily build from commit abc1234", "commit": "abc1234567890", } ] }由于开发经验所限,本 PR 大部分代码由 Rider 上的 Gemini Code Assist 和 GitHub Copilot 编写。如有需要改动的地方欢迎提出,我将在空闲时间进行修改。