...
这个不行，只能读取@version版本信息，跟version的来 王一之 发表于 2024-2-14 23:54
这个不行，只能读取@version版本信息，跟version的来
那是否可以考虑在Webhook功能中支持根据Payload中的prerelease布尔值确定推送的是否是预发布版本？ dawnl-lc 发表于 2024-2-15 18:13
那是否可以考虑在Webhook功能中支持根据Payload中的prerelease布尔值确定推送的是否是预发布版本？ ...
暂时没有考虑
根据@version有什么问题吗？ 本帖最后由 dawnl-lc 于 2024-2-16 18:31 编辑
王一之 发表于 2024-2-16 13:04
暂时没有考虑
根据@version有什么问题吗？
没啥问题，只是觉得GitHub已经实现的功能且webhook接口也提供了所需信息，就没必要再造轮子了，再在脚本里写一个从GM_info提取@version再解析语义化版本的方法多此一举。
另外我认为预发布版本和主要发布版本的区别不应在@version上，而应在@updateURL和@downloadURL中体现。我认为预发布版本应该像Windows的Canary通道一样，只接收预发布版本的更新，而主要发布版本只接收主要发布版本的更新，以避免由于版本行为差异导致的意外问题。
且用户使用哪个版本在理想情况下应由用户自行决定，灰度测试实际上是对用户选择权的侵犯。
dawnl-lc 发表于 2024-2-16 18:24
没啥问题，只是觉得GitHub已经实现的功能且webhook接口也提供了所需信息，就没必要再造轮子了，再在脚本里 ...
因为来源不止GitHub（其实之前也没想到过这个问题{:4_90:}），如果是GitHub的webhook来源可以根据pre release来判断一下（还没有这个功能，可以考虑一下）
至于怎么去决定预发布版本和主要版本，这只是一个方式上的选择，各有优劣，另外脚本站的预发布版本，只是如果你的@version符合上面我说的要求，会自动的标记预发布，你也可以自己手动的标记。这个之前忘记提了。
灰度测试和预发布版本这也是两样东西，用怎么样的策略也可以自己决定，哥哥可以在脚本管理的脚本发布里面看，至于涉及用户的选择权，这就是另外一个话题了。 dawnl-lc 发表于 2024-2-16 18:24
没啥问题，只是觉得GitHub已经实现的功能且webhook接口也提供了所需信息，就没必要再造轮子了，再在脚本里 ...
> 预发布版本和主要发布版本的区别不应在@version上，而应在@updateURL和@downloadURL中体现
关于这个，哥哥可以开个测试脚本，然后脚本管理->脚本发布开一下预发布，在url中是会有体现的 dawnl-lc 发表于 2024-2-16 18:24
没啥问题，只是觉得GitHub已经实现的功能且webhook接口也提供了所需信息，就没必要再造轮子了，再在脚本里 ...
> 预发布版本和主要发布版本的区别不应在@version上，而应在@updateURL和@downloadURL中体现
关于这个，哥哥可以开个测试脚本，然后脚本管理->脚本发布开一下预发布，在url中是会有体现的
页:
1
[2]