Apply suggestions from code review

Co-authored-by: lilyjma <[email protected]>

Author: AnatoliB

articles/azure-functions/durable/durable-functions-orchestration-versioning.md

@@ -12,7 +12,8 @@ ms.custom: fasttrack-edit
 # Orchestration Versioning in Durable Functions (Azure Functions)
 
 > [!IMPORTANT]
-> Orchestration Versioning is currently in public preview for apps running in the .NET isolated model. Support for other languages (JavaScript, Python, PowerShell, Java) is coming soon.
+> Orchestration Versioning is currently in public preview for apps running in the .NET isolated model. Use `Microsoft.Azure.Functions.Worker.Extensions.DurableTask` package version **>=1.5.0**.
+> Support for other languages (JavaScript, Python, PowerShell, Java) is coming soon.
 
 The Orchestration Versioning feature allows different versions of orchestrations to coexist and execute concurrently without conflicts and nondeterminism issues, making it possible to deploy updates without draining in-flight orchestration instances first. Thus, this feature brings various benefits related to deploying orchestration changes. For example, you can achieve zero-downtime deployment even making breaking changes to your orchestrations.
 
@@ -43,7 +44,7 @@ The Orchestration Versioning feature operates on these core principles:
 
 ## Basic usage
 
-The most common use case for Orchestration Versioning is when you need to make breaking changes to your orchestration logic while keeping existing in-flight instances running with their original version. All you need to do is update the `defaultVersion` in your `host.json` and modify your orchestrator code to check the version and branch execution accordingly. Let's walk through the required steps.
+The most common use case for Orchestration Versioning is when you need to make breaking changes to your orchestrator logic while keeping existing in-flight orchestrations instances running with their original version. All you need to do is update the `defaultVersion` in your `host.json` and modify your orchestrator code to check the version and branch execution accordingly. Let's walk through the required steps.
 
 ### Step 1: defaultVersion Configuration
 
@@ -98,7 +99,7 @@ public static async Task<string> RunOrchestrator(
 ---
 
 > [!NOTE]
-> The `context.Version` property is **read-only** and reflects the version that was permanently associated with the orchestration instance when it was created. You cannot modify this value during orchestration execution. If you need to specify a version in your app code, you can do so when starting the orchestration instance using the orchestration client APIs (see [Starting New Orchestrations with Specific Versions](#starting-new-orchestrations-with-specific-versions)).
+> The `context.Version` property is **read-only** and reflects the version that was permanently associated with the orchestration instance when it was created. You cannot modify this value during orchestration execution. If you want to specify a version through means other than `host.json`, you can do so when starting an orchestration instance with the orchestration client APIs, (see [Starting New Orchestrations with Specific Versions](#starting-new-orchestrations-with-specific-versions)).
 
 > [!TIP]
 > If you're just starting to use Orchestration Versioning and you already have in-flight orchestrations that were created before you specified a `defaultVersion`, it's not too late! Feel free to add the `defaultVersion` setting to your `host.json` now. For all previously created orchestrations, `context.Version` returns `null` (or an equivalent language-dependent value), so you can structure your orchestrator logic to handle both the legacy (null version) and new versioned orchestrations accordingly. In C#, you can check for `context.Version == null` or `context.Version is null` to handle the legacy case. Please also note that specifying `"defaultVersion": null` in `host.json` is equivalent to not specifying it at all.

articles/azure-functions/durable/durable-functions-versioning.md

@@ -206,15 +206,15 @@ Because of these potential failures, the "do nothing" strategy is not recommende
 > [!NOTE]
 > Orchestration Versioning is currently in public preview.
 
-Orchestration Versioning is a built-in feature that enables [zero-downtime deployments](durable-functions-zero-downtime-deployment.md) with breaking changes. This approach allows different versions of orchestrations to coexist and execute concurrently without conflicts.
+The Orchestration Versioning feature allows different versions of orchestrations to coexist and execute concurrently without conflicts and non-determinism issues, making it possible to deploy updates while allowing in-flight orchestration instances to complete without manual intervention.
 
 With Orchestration Versioning:
 - Each orchestration instance gets a version permanently associated with it when created
 - Orchestrator functions can examine their version and branch execution accordingly  
 - Workers running newer orchestrator function versions can continue executing orchestration instances created by older versions
 - The runtime prevents workers running older orchestrator function versions from executing orchestrations started by newer versions
 
-This strategy is recommended for applications that need to support breaking changes while maintaining [zero-downtime deployments](durable-functions-zero-downtime-deployment.md). The feature is currently available for .NET in-process and .NET isolated programming models.
+This strategy is recommended for applications that need to support breaking changes while maintaining [zero-downtime deployments](durable-functions-zero-downtime-deployment.md). The feature is currently available .NET isolated apps.
 
 For detailed configuration and implementation guidance, see [Orchestration Versioning in Durable Functions](durable-functions-orchestration-versioning.md).
 

articles/azure-functions/durable/durable-functions-zero-downtime-deployment.md

@@ -22,7 +22,7 @@ The following chart compares the four main strategies to achieve a zero-downtime
 
 | Strategy |  When to use | Pros | Cons |
 | -------- | ------------ | ---- | ---- |
-| [Orchestration Versioning](#orchestration-versioning) | Applications with [breaking changes](durable-functions-versioning.md), especially those that need to support concurrent execution of different orchestration versions. | Enables zero-downtime deployments with breaking changes.<br/>Built-in feature requiring minimal configuration. | Currently limited to .NET in-process and .NET isolated.<br/>Requires careful orchestrator code modifications for version compatibility. |
+| [Orchestration Versioning](#orchestration-versioning) | Applications with [breaking changes](durable-functions-versioning.md), especially those that need to support concurrent execution of different orchestration versions. | Enables zero-downtime deployments with breaking changes.<br/>Built-in feature requiring minimal configuration. | Currently limited to .NET isolated.<br/>Requires careful orchestrator code modifications for version compatibility. |
 | [Name-based Versioning](#name-based-versioning) |  Applications that don't experience frequent [breaking changes.](durable-functions-versioning.md) | Simple to implement. |  Increased function app size in memory and number of functions.<br/>Code duplication. |
 | [Status check with slot](#status-check-with-slot) | A system that doesn't have long-running orchestrations lasting more than 24 hours or frequently overlapping orchestrations. | Simple code base.<br/>Doesn't require additional function app management. | Requires additional storage account or task hub management.<br/>Requires periods of time when no orchestrations are running. |
 | [Application routing](#application-routing) | A system that doesn't have periods of time when orchestrations aren't running, such as those time periods with orchestrations that last more than 24 hours or with frequently overlapping orchestrations. | Handles new versions of systems with continually running orchestrations that have breaking changes. | Requires an intelligent application router.<br/>Could max out the number of function apps allowed by your subscription. The default is 100. |
@@ -39,11 +39,11 @@ The [Orchestration Versioning](durable-functions-orchestration-versioning.md) fe
 With Orchestration Versioning:
 - Each orchestration instance gets a version permanently associated with it when created.
 - Workers running newer versions can continue executing orchestration instances created by older versions.
-- Workers running older versions are prevented from executing orchestrations started by newer versions.
+- Workers running older orchestration versions _can't_ execute newer version instances.
 - Orchestrator functions can examine their version and branch execution accordingly.
 
 This approach facilitates rolling upgrades where workers running different versions of your application can coexist safely. It's the recommended strategy for applications that need to support breaking changes while maintaining zero-downtime deployments.
-
+The Orchestration Versioning feature is **[backend agnostic](./durable-functions-storage-providers.md)**, so you can leverage it regardless of what storage backend your Durable Function app is using. 
 For detailed configuration and implementation guidance, see [Orchestration Versioning in Durable Functions](durable-functions-orchestration-versioning.md).
 
 ## Name-based Versioning

includes/functions-host-json-durabletask.md

@@ -109,7 +109,7 @@ Task hub names must start with a letter and consist of only letters and numbers.
 |Property  |Default | Description |
 |---------|---------|----------|
 |hubName|TestHubName (DurableFunctionsHub if using Durable Functions 1.x)|Alternate [task hub](../articles/azure-functions/durable/durable-functions-task-hubs.md) names can be used to isolate multiple Durable Functions applications from each other, even if they're using the same storage backend.|
-|defaultVersion||The default version to assign to new orchestration instances. When specified, new orchestration instances are permanently associated with this version value. Used by the [Orchestration Versioning](../articles/azure-functions/durable/durable-functions-orchestration-versioning.md) feature to enable zero-downtime deployments with breaking changes. You can use any string value for the version.|
+|defaultVersion||The default version to assign to new orchestration instances. When specified, new orchestration instances are permanently associated with this version value. Used by the [Orchestration Versioning](../articles/azure-functions/durable/durable-functions-orchestration-versioning.md) feature to enable scenarios like zero-downtime deployments with breaking changes. You can use any string value for the version.|
 |versionMatchStrategy|CurrentOrOlder|Determines how orchestration versions are matched when loading orchestrator functions. Valid values are `None`, `Strict`, and `CurrentOrOlder`. For detailed explanations, see [Orchestration Versioning](../articles/azure-functions/durable/durable-functions-orchestration-versioning.md).|
 |versionFailureStrategy|Reject|Determines what happens when an orchestration version does not match the current `defaultVersion`. Valid values are `Reject` and `Fail`. For detailed explanations, see [Orchestration Versioning](../articles/azure-functions/durable/durable-functions-orchestration-versioning.md).|
 |controlQueueBatchSize|32|The number of messages to pull from the control queue at a time.|