接纳一个新的上游版本

平台对上游框架采用精确锁定策略：每个已发布版本 = recipe 版本矩阵里的一个变体 + runtime registry 里的一个执行工件。跟进新版本是声明式流程，多数情况不改平台代码。

步骤

构建执行工件

为新版本构建训练镜像（K8s/Docker：OCI digest 固定）或 SIF/SQSH（Slurm），发布到 runtime registry，分配 runtime_id。

声明版本变体

在 recipe YAML 的 runtime.versions 增加新版本项：runtime_id、依赖、以及版本绑定的差异——入口覆盖（entrypoint）、参数路径覆盖（path_overrides）、观测补丁认证版本（observer_versions）。

跑适配测试

SDK 单测覆盖版本矩阵（入口 / 参数路径 / 观测按版本断言）；tests/ 全量回归。

灰度发布

新版本先不设为 default_version：想尝鲜的用户 tp new --framework-version X / tp recipe upgrade --framework-version X 显式选用。稳定后再切默认。

用户升级

catalog 发布后，存量实验锁提示漂移；用户 tp recipe upgrade 显式升级——没有静默切换。

框架	常见差异点
NeMo-RL	官方 YAML 基底更新（同步 `configs/base/`）、Megatron/DTensor 配置键迁移
verl	训练入口整合（如 0.9 的 main_ppo 统一）、Ray 版本要求
TRL	Trainer API 签名变化、Accelerate 配置默认值

三件看起来像捷径、其实不是的事：

不要	因为
在适配器代码里写 `if version >= X` 分支	版本差异属于 recipe 声明，读的人在那里能看见它们
用 `latest` 或一个分支名当版本	只接受精确 semver 或完整 commit。一个会动的版本让”同一个” recipe 的两次运行不可比
让一个已有的 `runtime_id` 指向新镜像	产物不可变。新镜像，新 id —— 否则一个钉了旧 digest 的作业无法复现

tp methods verl/grpo

新的框架版本出现在这个方法的版本列表里。然后显式建一个实验对着它提交一次：

tp new canary-verl --method verl/grpo --framework-version 0.9.1
tp submit canary-verl --profile h200:8

一个到达 RUNNING 并报出第一个指标的作业，说明镜像、入口和 observer 都对上了。