Address feedback

- Fix minor typos
- Move the public preview note
- Remove redundant explanation of Orchestration Versioning benefits for clarity
- Add backend agnostic benefit to Orchestration Versioning section
- Rename section "How to handle breaking changes" to "Types of breaking changes" for clarity

Author: AnatoliB

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

@@ -11,12 +11,6 @@ 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. 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.
-
 ## Overview
 
 Orchestration Versioning addresses the core challenge of deploying changes to orchestrator functions while maintaining the deterministic execution model that Durable Functions requires. Without this feature, breaking changes to orchestrator logic or activity function signatures would cause in-flight orchestration instances to fail during replay because they would break the [determinism requirement](durable-functions-code-constraints.md) that ensures reliable orchestration execution.
@@ -29,6 +23,7 @@ Sub-orchestrations can also leverage this feature.
 - **Rolling upgrades**: Workers running different versions of orchestrator code can coexist safely.
 - **Automatic version isolation**: The runtime ensures version compatibility automatically.
 - **Minimal configuration**: Built-in feature requiring only basic `host.json` configuration.
+- **Backend agnostic**: Feature can be used by apps leveraging any of the Durable Function's [storage backends](durable-functions-storage-providers.md).
 
 ### How It Works
 
@@ -42,9 +37,13 @@ The Orchestration Versioning feature operates on these core principles:
 
 1. **Forward Protection**: The runtime automatically prevents workers running older versions from executing orchestrations started by newer versions.
 
+> [!IMPORTANT]
+> 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.
+
 ## Basic usage
 
-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.
+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 orchestration 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
 
@@ -99,7 +98,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 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)).
+> 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

@@ -11,7 +11,7 @@ ms.author: azfuncdf
 
 It is inevitable that functions will be added, removed, and changed over the lifetime of an application. [Durable Functions](durable-functions-overview.md) allows chaining functions together in ways that weren't previously possible, and this chaining affects how you can handle versioning.
 
-## How to handle breaking changes
+## Types of breaking changes
 
 There are several examples of breaking changes to be aware of. This article discusses the most common ones. The main theme behind all of them is that both new and existing function orchestrations are impacted by changes to function code.