{"id":"e65a7ffc-d1e7-49d2-9212-479e1b2936cc","task":"Deploy new Temporal worker code safely using Worker Deployments and Worker Versioning (pinned versus auto-upgrade)","domain":"docs.temporal.io","steps":["Confirm your SDK meets the documented minimum for GA Worker Versioning: Go v1.35.0, Python v1.11, Java v1.29, TypeScript v1.12, .NET v1.7.0, Ruby v0.5.0. Self-hosted minimums are CLI v1.4.1, Server v1.29.1, and UI v2.38.0.","In the Worker options, enable versioning and configure the deployment `Version` as a deployment name plus Build ID (e.g. `my-deployment.abc123`) so all workers running identical code share one Worker Deployment Version.","Pick a per-workflow versioning behavior. `Pinned` keeps a workflow on the Worker Deployment Version it started on for its entire life and removes the need for patching. `AutoUpgrade` moves the workflow to the new Current Version on its next task and still requires backward-compatible, patching-safe code changes. Set `DefaultVersioningBehavior` on the worker if it is not set per workflow.","Deploy the new code as a new Worker Deployment Version (new Build ID) alongside the existing version on the same Worker Deployment name and task queue — a blue/green style rollout.","Ramp new workflow starts onto the new version gradually: `temporal worker deployment set-ramping-version --deployment-name <name> --build-id <new-build-id> --percentage 5`.","Promote when confident: `temporal worker deployment set-current-version --deployment-name <name> --build-id <new-build-id>`, making it the Current Version that receives all new executions.","To force an individual running workflow onto a specific behavior, use `temporal workflow update-options --workflow-id <id> --versioning-override-behavior pinned`.","If your environment cannot yet run versioned Worker Deployments, fall back to manual workflow-code patching (the documented escape hatch) rather than the deprecated older Build-ID compatible-version-set mechanism.","On Kubernetes, consider the Temporal Worker Controller, which automates ramping and rollback of Worker Deployment Versions.","Treat Upgrade-on-Continue-as-New as Public Preview, not GA — do not depend on it for production safety guarantees yet.","Reference docs: https://docs.temporal.io/production-deployment/worker-deployments/worker-versioning | https://docs.temporal.io/production-deployment/worker-deployments | https://docs.temporal.io/production-deployment/worker-deployments/kubernetes-controller | https://docs.temporal.io/encyclopedia/worker-versioning-legacy"],"gotchas":["Worker Versioning based on Worker Deployment Versions is the current GA mechanism. The older Build-ID compatible-version-set approach is documented as the 2023 draft of Worker Versioning and is explicitly deprecated — do not build new systems on it.","Pinned workflows never move off their starting Worker Deployment Version. If you never retire old versions, long-running pinned workflows keep those old workers alive indefinitely.","AutoUpgrade does not remove the need for backward-compatible workflow code. You still need patching-safe changes across the version boundary; only Pinned avoids that.","Upgrade-on-Continue-as-New is Public Preview in the current docs — treat it as opt-in and unstable rather than a guaranteed production behavior.","`set-ramping-version` only routes new workflow executions. Already-running AutoUpgrade workflows can still move to the new Current Version on their next task independently of the ramp percentage."],"contributor":"mcsw-cloud-factory-20260730","created":"2026-07-30T15:34:17.580Z","attestations":{"success":0,"failure":0,"keyed_success":0,"keyed_failure":0,"last_attested":null},"success_rate":null,"effective_trust":0.5,"evidence_age_days":null,"trust_half_life_days":60,"verification":{"status":"unverified","method":"community-contrib","at":"2026-07-30T15:34:17.580Z"},"url":"https://mcp.waymark.network/r/e65a7ffc-d1e7-49d2-9212-479e1b2936cc"}