仓颉 STS 1.1.x，官网 Release Notes 写的是：计划在 2026 年 10 月 30 日停止维护。那天前后，我们还钉着 1.1 的工程，反复问：旧 SDK 继续熬，还是咬牙升到 1.2？1.2.0 其实早在 2026 年 9 月 22 日就挂上了下载页，维护周期写的是 6 个月。真正让人难受的，往往是那句「和早期 SDK 二进制不兼容，项目和依赖都要全量重编」------功能清单反而往后排。这篇按我们自己的取舍写：停维日怎么选、1.2 值得先看哪几处、升版要整棵依赖一起重编时窗口怎么排，以及对外交付为什么钉 STS tip。
一、停维日那天我们在纠结什么
停维日，不等于下载页突然变空白。官网写的是「计划」停止维护，我们按这个词理解：别写成全渠道已经下架。
真正难的是排优先级：升，还是继续钉 1.1，两边都要付出些什么。对照图见下，两边各押什么，这儿就不逐条念了。
我们这边升版踩坑还没清完，所以这篇不讲「我们已经全量迁完」。只讲停维窗口前后，我们怎么排优先级。
有人会问：下载页 9 月 22 日就挂了 1.2.0，为什么拖到停维日才慌？中间差的是回归窗口够不够、依赖齐不齐------挂上发布，不等于马上能动工。
二、1.2 值得先看的几处
相对 1.1.3，1.2.0 差在哪，对照图见下。细节别逐行背；升版费不费劲，先看图里标重的那一行。
先问自己：图里这几处，有没有挡住你现在的交付。 没有，就别为了「新」硬排一整周重编。
三、真正卡人的一句：全量重编
Release Notes 变更特性表写得很直：这个版本和早期 SDK 编出来的二进制不兼容，混着用，运行时可能报错。办法是用本版本及更新的 SDK，把项目代码和依赖包一起全量重编。
窗口怎么估、哪几项会先卡住，对照图见下------细节不在这儿再念一遍。
还有一处会逼你改代码，但比上面好办：静态成员初始化检查加强了。在函数或 lambda 里给静态成员赋值会报错，得改到定义处，或写到 static init()。编译期就能看见，比二进制混用好对付，升版清单里别漏。
|----------|-------------------|-------------------|
| 维度 | 1.1.x 侧 | 升到 1.2.0 |
| 维护口径（RN） | 计划 2026.10.30 停维 | STS，维护周期 6 个月 |
| 下载页发布日 | --- | 2026/09/22 |
| 二进制兼容 | LTS 1.0.0 后版本间曾兼容 | 与早期 SDK 不兼容，须全量重编 |
| 我们怎么排 | 能拖就先钉 tip | 有窗口才整棵依赖重编+回归 |
四、交付钉 STS，尝鲜再跟 Nightly
对外交付要稳，想尝鲜可以另开一条线。两边怎么钉、对外说明里哪些话不能写，对照图见下。
我们这轮对部分 GitCode 入口还不稳定，具体构建号这篇就不报。
如果你也在纠结要不要升，可以按这个顺序动手：先读 Release Notes 变更特性表里那一行「全量重编」；再列依赖锁和 CI 镜像；最后才排跨平台新能力要不要在本迭代启用。顺序反了，很容易为了一两个新特性，把整周回归窗口烧掉。
结语
1.1 的计划停维日过了，纠结不会自己消失。对照图把差异摊开了，可真正贵的还是整棵依赖一起重编。我们还在自己的升版清单里抠细节，不急着喊已经迁完。你要是也卡在升不升级这件事上，先把重编窗口和依赖锁写清楚，再谈要不要升。
参考
- Cangjie 1.2.0 Release Notes（取页 2026-11-01 20:03 Asia/Singapore）
- 仓颉下载中心 · 1.2.0（发布日期 2026/09/22；取页同上）