Recommend Worker Versioning by default (#4349)

Author: bechols

docs/best-practices/worker.mdx

@@ -169,15 +169,19 @@ Use Worker Versioning to deploy new Workflow code without breaking running Execu
 each Workflow Execution to a specific Worker Deployment Version identified by a build ID, which guarantees that pinned
 Workflows always run on the same Worker version where they started.
 
+For most teams, Worker Versioning should be the default approach for evolving Workflow code in production. It gives you
+safer rollouts, clearer rollback behavior, and a cleaner operational model than maintaining multiple code paths inside a
+Workflow definition.
+
 To learn more about versioning Workflows, see the
 [Workflow Versioning](/production-deployment/worker-deployments/worker-versioning.mdx) guide or take our
 [Worker Versioning course](https://learn.temporal.io/courses/worker_versioning/).
 
 :::tip
 
-In addition to Worker Versioning, you can also use [Patching](/patching) to introduce changes to your Workflow code
-without breaking running Executions. Patching reduces complexity on the infrastructure side compared to Worker
-Versioning, but it introduces some complexity on the Workflow code side. Choose the approach that best fits your needs.
+If your deployment environment cannot yet support Worker Versioning, you can use [Patching](/patching) to introduce
+changes to your Workflow code without breaking running Executions. Treat patching as a fallback for environments that
+cannot adopt versioned worker deployments yet, not as the default recommendation.
 
 :::
 

docs/production-deployment/worker-deployments/index.mdx

@@ -24,7 +24,12 @@ Once you have an understanding of the core concepts, the content in this section
 
 Our Worker Deployments guide provides documentation of Temporal product features that make it easier to scale and revise your Workflows.
 
-[Worker Versioning](/production-deployment/worker-deployments/worker-versioning) allows you to pin Workflows to individual versions of your workers, which are called Worker Deployment Versions.
+[Worker Versioning](/production-deployment/worker-deployments/worker-versioning) is the recommended default for safely
+deploying new Workflow code. It allows you to pin Workflows to individual versions of your workers, which are called
+Worker Deployment Versions.
+
+If your environment cannot yet support versioned worker deployments, you can fall back to patching Workflow code.
+However, new production deployments should prefer Worker Versioning whenever possible.
 
 You can optionally use the Temporal [Worker Controller](/production-deployment/worker-deployments/kubernetes-controller) to programmatically manage and scale your Worker deployments in Kubernetes pods.
 

docs/production-deployment/worker-deployments/worker-versioning.mdx

@@ -24,6 +24,9 @@ Worker Versioning is a Temporal feature that allows you to confidently deploy ne
 your Workers without breaking them. Temporal enables this by helping you manage different builds or versions, formally
 called [Worker Deployment Versions](/worker-versioning#deployment-versions).
 
+For most teams, Worker Versioning should be the default recommendation for deploying Workflow code changes in
+production. If you can run versioned worker deployments, prefer Worker Versioning over patching.
+
 Worker Versioning unlocks important benefits for users of [blue-green or rainbow deployments](#deployment-systems).
 
 - Ramping traffic gradually to a new Worker Deployment Version.
@@ -133,6 +136,9 @@ rainbow deployments of your Workers if you're using Kubernetes.
 
 :::
 
+If you cannot yet support blue-green or rainbow style deployments, use [patching](/patching) as a fallback while you
+work toward a versioned deployment model.
+
 ## Configuring a Worker for Versioning
 
 You'll need to add a few additional configuration parameters to your Workers to toggle on Worker Versioning. There are