Skip to main content
Every published version is one entry in a recipe’s version matrix plus one artifact in the runtime registry. Adopting a new upstream release is declarative: in most cases nothing in the platform’s own code changes.

​
The steps

1

Build the execution artifact

Build the training image for the new version (K8s/Docker: OCI digest-pinned) or SIF/SQSH (Slurm), publish it to the runtime registry, and assign a runtime_id.
2

Declare the version variant

Add a new version entry under runtime.versions in the recipe YAML: runtime_id, dependencies, and the version-bound differences — entrypoint override (entrypoint), parameter path overrides (path_overrides), and certified observer patch versions (observer_versions).
3

Run adaptation tests

SDK unit tests cover the version matrix (entrypoint / parameter paths / observers asserted per version); full regression via tests/.
4

Canary release

Do not make the new version default_version at first: early adopters opt in explicitly with tp new --framework-version X / tp recipe upgrade --framework-version X. Switch the default once it is stable.
5

User upgrade

After the catalog is published, existing experiment locks show drift hints; users upgrade explicitly with tp recipe upgrade — there is no silent switching.

​
Framework-specific notes

​
What not to do

Three things that look like shortcuts and are not:

​
Check it worked

The new framework version appears in the method’s version list. Then create an experiment against it explicitly and submit once:
A job that reaches RUNNING and reports its first metric means the image, the entrypoint and the observer all line up.

​
Next

Method catalogue · Recipe packs · Maintenance mode