目标
支持一个旧版本是一项承诺：哪些修复、支持多久、升级路径是什么。先发布政策，分支才是受管理的产品；含糊不清的话，它只是安全修复永远到不了的坟场。公开的回移植台账让承诺可核对，分级催告让终点成为被管理的迁移。
步骤要点
- 先发布支持政策：LTS 分支接收哪些内容（安全修复、严重缺陷）、支持截止日期，并让主要消费者确认知晓。
- 每次常规发布做回移植分诊：哪些必须回移植（安全、严重）、哪些仅主线，逐条登记台账。
- 带测试回移植：连测试一起 cherry-pick，仅在 API 分叉处适配，每个回移植 PR 跑 LTS 分支套件。
- 按节奏发 LTS 补丁版本，发布说明明确区分 LTS 补丁与主线版本。
- 支持期临近时按 90/30/7 天递进催告升级，验证升级路径可用，到期归档分支。
排错提示
安全通告发出但 LTS 补丁迟迟未到是回移植容量没预留，把回移植工时写进团队容量规划；回移植后 LTS 套件变红说明只拣了代码没拣测试或没适配 API 差异，补齐测试再合并；EOL 当天才通知引发消费者愤怒，提前三波催告加验证过的升级指南才是管理式迁移。
适用边界
回移植的成本随主线偏离度上升，超过两个大版本分歧时应评估收敛而非继续背；承诺的修复时限依赖人力稳定，政策要写明极端情况下的宽限与通知机制。
代码示例
LTS 1.x (support policy v2)
receives: security (<=7d), critical (<=14d)
NOT: features, refactors, mainline deprecations
end-of-support: 2027-04-30
backport ledger (excerpt):
CVE-2026-4411 auth bypass backported 2d v1.8.9
#4921 rounding critical backported 5d v1.8.9
#5102 caching main-only (not qualifying)
EOL nudges: 2027-01-30 / 2027-03-30 / 2027-04-23