何木槿 l zw 22624.1465来力,移了少量功能下来() 估计23xxx正式roll out悬了,微软我***(友好问候) 毕竟22000.1→22000.41也是321→421,WFEP也跨了100(
l zw 何木槿 不过.1465(22640)还是623。 毕竟23550就是上限了,不太可能进Retail。按照每个工作日Build+1,也只能到九月底。我倒是期待那之后Dev会推什么。 ThinkBou 然而SystemApps不就是随CU更新吗?不然就变成了非系统应用。除非WFEP也通过商店更新。
何木槿 l zw 23550就是上限了 垃圾网络又抽风复读力(悲) 这话我不知道在哪里见过,能否给一下出处? BTW,那么24xxx这一段基本就等于是被放弃了?远景有人用20277->21277举例,但是20277->21277中间也还是夹着一些Build啊(
l zw 何木槿 23550不是有rs_prerelease的版本吗?按照规律,正式版本一般不会与下一周期早期测试版的版本号重合,比如16299即使重新编译个16299.15,也不会突破16300。24xxx不一定不存在,但不太可能推送。 ThinkBou 某人我也不认识啊。我根本不知道有这事。 psfx CU展开体积翻两倍以上,然而展开后也只是delta,应用delta后应该还要翻三五倍。反向分析,60MB的文件对CU大小的影响并不大。况且WinAppRT有一半的文件平常更新是基本不变的,甚至完全不变。
ThinkBou ThinkBou 对于微软来说,通过服务技术(也就是累积更新)更新WinAppRT.CBS是几乎不可能的,所以会直接推送新版本。 不过微软还是这么做了…… l zw psfx CU展开体积翻两倍以上,然而展开后也只是delta,应用delta后应该还要翻三五倍。反向分析,60MB的文件对CU大小的影响并不大。况且WinAppRT有一半的文件平常更新是基本不变的,甚至完全不变。 嗯,一下子就涨了得有40MB
l zw 新发现:23403有22622/22623相关组件,也就是可以“升级”到22622/22623,但不包括22624。 由此推断,234xx应该是从M2就和Beta分道扬镳了。但231xx又被认为是M3,那就只有两种可能:231xx并不是M3,或者231xx和234xx没有接续关系。 此从有了betaflt分支,好像Retail/Beta/Dev(ni_prerelease)都是平行开发的,完全找不到规律了。
提本狐 l zw 新发现:23403有22622/22623相关组件,也就是可以“升级”到22622/22623,但不包括22624。 实测还真可以 但是全部移除后还是23403 本以为会是22621🤔
何木槿 提本狐 毕竟是经过了重新编译的,卸载完回到23403很正常,“降级”也挺有意思,倒是真的22621装上23403内含的Moment包会咋样 似乎Moment的虚拟版本号还挺瓷实,我在20348上成功了几次,但没弄出成型的产物