SteveWorkshop 我突然发现现在的beta是最憋屈的通道
一开始22622呼呼呼下放功能甚至还跟当时的dev还能互通有无，那时vivetool玩的不亦乐乎
后来dev改变策略，新功能全在dev，23623几乎等于耍猴
现在can上位，beta 22624真成耍猴的东西了
Well…微软关于Moments测试的态度一直没有改变。Beta通道始终都是只测一个Moments的功能；旧Dev那是功能超前开发，要是按照Beta的测试速度安排开发，那么多功能肯定写不完……
SteveWorkshop lzw说1800左右会有最后一次下放
其实直到生命周期结束，OS的新增功能才会停止。看看Windows 11 21H2就是最好的例子。
ThinkBou 说不定只是程序员用rust，编译器照样转成c
gailium119 但在底层用 Rust 已经是个巨型进步了
zn_release branch incoming
Famous 说不定明天server 25852就来了，和之前25057一样
Famous 目前已知Moment 4的ID：42105254（1285421709），22621已经有了，但默认禁用（234xx默认启用），据此推测有22625。（22625到底有没有很快就能知道了）
我目前认为ni_prerelease只是一个类似于之前内部ni_moment的分支，目前在测SV2M4，不会有正式版，也就不必进入Beta。
跟据我对启用包的研究，22625（如果有）一推送就不会再改变DisplayVersion和UpdateDescription，也就是不存在22625从Beta转Retail的情况。
Moment 5+既没有开发版本空间也没有已知ID，存在可能性比较小。
何木槿 Xbox推Zn为2308正式版是确定的，之前Mn和Fe这些都没推给Xbox，Xbox和Client正式版进度一样，都是18362-18363-19041-22000-22621，由此认为zn_release将有Client正式版。
按照微软弃18362.100xx、Mn、Fe而以18363、19042、19043代之的策略，启用包能解决的就绝不会用完整更新。如果真要启用包实现不了的新功能又不如推zn_release。
gailium119
至少得下周了
何木槿 是2308，改了。Xbox一直是.1000+起步，然后还会+500的跳
gailium119 但还是有些已知问题。
l zw Xbox推Zn为2208正式版是确定的，之前Mn和Fe这些都没推给Xbox，Xbox和Client正式版进度一样，都是18362-18363-19041-22000-22621，由此认为zn_release将有Client正式版。
23H2（确信）
按此推测未来的变化可能呈现这样的状态：Dev→Zinc，Canary→Gallium，Beta→22625→Zinc
不过如果按照 ThinkBou 的说法，每个团队现在都能择其所好了
l zw Zn为2208正式版
不应该是2308吗（
Xbox的8月大更新命名已经持续了两年了。
不过Xbox的更新挺有意思，出现了Client里没有的版本号，还带着修订版本号
ThinkBou 客户端的LTSC一定基于在发布当时已发布的客户端版本，微软不会把阵线拉得太长。
这倒是，不过Server就不一样了
gailium119 毕竟已经试过一次了[tieba=huaji]
只要有UUP，搓出来又不是不能用，说不定还能好用[tieba=huaji]
ThinkBou 反正Zinc还是很有希望出现生产签名的产物的，我只想把我的Windows平台尽快迁移到一个新而稳定的地方。
Famous 即使是属于24H2周期
个人认为，周期是一个Windows平台范畴内的概念，不要随意限定其内涵或扩展其外延。
Famous 我还记得微软在去年曾经说过Moments至少有4次大更新
微软没有说过，只是得知一些消息的媒体独家爆料了这个事情。
不要将媒体的话等价于微软的话。
何木槿 转到企业或服务器版本，发布11 LTSC
Well…客户端的LTSC一定基于在发布当时已发布的客户端版本，微软不会把阵线拉得太长。
l zw Moment 5+既没有开发版本空间
我不是很能理解这个版本空间是什么。对于微软来说，版本号是够用的。
l zw 启用包能解决的就绝不会用完整更新。
对于微软来说，通过服务技术（也就是累积更新）更新WinAppRT.CBS是几乎不可能的，所以会直接推送新版本。不过你在做出这些推断时
Xbox推Zn为2308正式版是确定的，之前Mn和Fe这些都没推给Xbox，Xbox和Client正式版进度一样，都是18362-18363-19041-22000-22621，由此认为zn_release将有Client正式版。
如果真要启用包实现不了的新功能又不如推zn_release。
我建议你注意一下这件事情：
何木槿 Dev走完ni_prerelease后，要么下放23xxx到Beta，然后和Canary合并，要么继续帮Beta测试Moment的牙膏。
Famous zn_release下放Dev通道后，Beta通道可能的两种选择：
1测ni_prerelease。
2继续测ni_release，ni_prerelease分支废弃
何木槿 按此推测未来的变化可能呈现这样的状态：Dev→Zinc，Canary→Gallium，Beta→22625→Zinc
Dev大概概率不会在未确定下一个Windows 11功能更新的平台的时候切换平台，也就是不同周期的内核。如果Windows 11将一直停留在Ni周期22H2平台，那么Dev将直到Windows 12发布后开测才会收到不属于Ni周期的版本；也有可能在Windows 12的平台进入了release以后，Dev会切入，但是这个时候的版本不会有任何显著的UX变化，就像Win10_CO那些版本一样。按照目前已知信息，Windows 12很可能将于2024年第一季度发布。
l zw 就算没有client正式版也大概率有server/hci的正式版，靠uup文件拼凑能和20348一样拼出个能用的client（还不会收到更新多好）
根据这张图片里的信息和其它一些信息
推测一些事情：
1.Windows 11 23H2不会基于Zn周期23H2平台发布。
2.Windows Server vNext或Azure Stack HCI 23H2可能基于Zn周期23H2平台发布，且客户端体验与SV2M2的功能一致。
3.到SV2M2，微软应该终于完成了原定于SV2开发的功能，比如文件资源管理器标签页和全部刷新了的任务栏，而SV2M3+主要包括原定SV3的一些计划。如此拉长开发战线，我实在怀疑Windows客户端团队的人手和水平够不够、好不好，以及在这种情况下，他们要做出一个什么样的Hudson Valley……
删封申诉 | 知乎专栏 | 状态监控 | 用户协议(EULA) | 隐私政策
本站文章除其作者特殊声明外，一律采用CC BY-NC-SA 4.0许可协议进行授权，进行转载或二次创作时务必以相同协议进行共享，严禁用于商业用途。
。
，锌线最后还是要回归到镍线