Lowercase "orchestration versioning"

Author: AnatoliB

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

@@ -1,6 +1,6 @@
 ---
-title: Orchestration Versioning in Durable Functions - Azure
-description: Learn how to use the Orchestration Versioning feature in Durable Functions for zero-downtime deployments involving breaking changes.
+title: Orchestration versioning in Durable Functions - Azure
+description: Learn how to use the orchestration versioning feature in Durable Functions for zero-downtime deployments involving breaking changes.
 author: AnatoliB
 ms.topic: conceptual
 ms.date: 07/03/2025
@@ -9,11 +9,11 @@ ms.custom: fasttrack-edit
 #Customer intent: As a Durable Functions developer, I want to deploy breaking changes to my orchestrations without interrupting in-flight instances, so that I can maintain zero-downtime deployments.
 ---
 
-# Orchestration Versioning in Durable Functions (Azure Functions)
+# Orchestration versioning in Durable Functions (Azure Functions)
 
 ## Overview
 
-Orchestration Versioning addresses [the core challenge](durable-functions-versioning.md) 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.
+Orchestration versioning addresses [the core challenge](durable-functions-versioning.md) 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.
 
 Sub-orchestrations can also leverage this feature. 
 
@@ -35,7 +35,7 @@ Understanding this distinction is crucial for orchestration versioning, where th
 
 ### How it works
 
-The Orchestration Versioning feature operates on these core principles:
+The orchestration versioning feature operates on these core principles:
 
 1. **Version Association**: When an orchestration instance is created, it gets a version permanently associated with it.
 
@@ -46,12 +46,12 @@ The Orchestration Versioning feature operates on these core principles:
 3. **Forward Protection**: The runtime automatically prevents workers running older orchestrator versions from executing orchestrations started by newer orchestrator 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**.
+> 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 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 orchestration 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 orchestration version and branch execution accordingly. Let's walk through the required steps.
 
 > [!NOTE]
 > The behavior described in this section targets the most common situations, and this is what the default configuration provides. However, it can be modified if needed (see [Advanced usage](#advanced-usage) for details).
@@ -121,7 +121,7 @@ public static async Task<string> RunOrchestrator(
 > 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`, you can still 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.
+> If you're just starting to use orchestration versioning and you already have in-flight orchestrations that were created before you specified a `defaultVersion`, you can still 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.
 
 > [!TIP]
 > Depending on your situation, you may prefer branching on different levels. You can make a local change precisely where this change is required, like the example shows. Alternatively, you can branch at a higher level, even at the entire orchestrator implementation level, which introduces some code duplication, but may keep the execution flow clear. It's up to you to choose the approach that best fits your scenario and coding style.
@@ -143,7 +143,7 @@ Here's what to expect once you deploy your updated orchestrator function with th
 
 ### Example: Replacing an activity in the sequence
 
-This example shows how to replace one activity with a different activity in the middle of a sequence using Orchestration Versioning.
+This example shows how to replace one activity with a different activity in the middle of a sequence using orchestration versioning.
 
 #### Version 1.0
 
@@ -365,7 +365,7 @@ Over time, you may want to remove legacy code paths from your orchestrator funct
    - **Solution**: This is expected behavior. The runtime intentionally prevents older workers from executing orchestrations with newer versions to maintain safety. Ensure all workers are updated to the latest orchestrator version and their `defaultVersion` setting in `host.json` is updated accordingly. You can modify this behavior if needed using the advanced configuration options (see [Advanced usage](#advanced-usage) for details).
 
 - **Issue**: Version information isn't available in orchestrator (`context.Version` is null, regardless of the `defaultVersion` setting)
-   - **Solution**: Verify that you're using a supported language and a Durable Functions extension version that supports Orchestration Versioning:
+   - **Solution**: Verify that you're using a supported language and a Durable Functions extension version that supports orchestration versioning:
      - For .NET Isolated, use `Microsoft.Azure.Functions.Worker.Extensions.DurableTask` version **1.5.0** or later.
 
 - **Issue**: Orchestrations of a newer version are making very slow progress or are completely stuck

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

@@ -186,7 +186,7 @@ This change adds a new function call to *SendNotification* between *Foo* and *Ba
 Here are some of the strategies for dealing with versioning challenges:
 
 * Do nothing (not recommended)
-* Orchestration Versioning (recommended in most cases)
+* Orchestration versioning (recommended in most cases)
 * Stop all in-flight instances
 * Side-by-side deployments
 
@@ -204,19 +204,19 @@ Because of these potential failures, the "do nothing" strategy is not recommende
 ### Orchestration versioning
 
 > [!NOTE]
-> Orchestration Versioning is currently in public preview.
+> Orchestration versioning is currently in public preview.
 
-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.
+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:
+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 of 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 .NET isolated apps.
 
-For detailed configuration and implementation guidance, see [Orchestration Versioning in Durable Functions](durable-functions-orchestration-versioning.md).
+For detailed configuration and implementation guidance, see [Orchestration versioning in Durable Functions](durable-functions-orchestration-versioning.md).
 
 ### Stop all in-flight instances
 
@@ -248,7 +248,7 @@ When doing side-by-side deployments in Azure Functions or Azure App Service, we
 ## Next steps
 
 > [!div class="nextstepaction"]
-> [Learn about Orchestration Versioning](durable-functions-orchestration-versioning.md)
+> [Learn about orchestration versioning](durable-functions-orchestration-versioning.md)
 
 > [!div class="nextstepaction"]
 > [Learn about using and choosing storage providers](durable-functions-storage-providers.md)

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

@@ -15,15 +15,15 @@ The [reliable execution model](./durable-functions-orchestrations.md) of Durable
 
 To prevent these failures from happening, you have several options: 
 - Delay your deployment until all running orchestration instances have completed.
-- Use [Orchestration Versioning](durable-functions-orchestration-versioning.md) to allow different versions of orchestrations to coexist (recommended).
+- Use [orchestration versioning](durable-functions-orchestration-versioning.md) to allow different versions of orchestrations to coexist (recommended).
 - Make sure that any running orchestration instances use the existing versions of your functions. 
 
 The following chart compares the four main strategies to achieve a zero-downtime deployment for Durable Functions: 
 
 | 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 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. |
+| [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. |
 
@@ -32,21 +32,21 @@ The remainder of this document describes these strategies in more detail.
 > [!NOTE]
 > The descriptions for these zero-downtime deployment strategies assume you are using the default Azure Storage provider for Durable Functions. The guidance may not be appropriate if you are using a storage provider other than the default Azure Storage provider. For more information on the various storage provider options and how they compare, see the [Durable Functions storage providers](durable-functions-storage-providers.md) documentation.
 
-## Orchestration Versioning
+## Orchestration versioning
 
-The [Orchestration Versioning](durable-functions-orchestration-versioning.md) feature allows you to make breaking changes to orchestrations while avoiding downtime during deployments. This built-in feature enables different versions of orchestrations to coexist and execute concurrently without conflicts.
+The [orchestration versioning](durable-functions-orchestration-versioning.md) feature allows you to make breaking changes to orchestrations while avoiding downtime during deployments. This built-in feature enables different versions of orchestrations to coexist and execute concurrently without conflicts.
 
-With Orchestration Versioning:
+With orchestration versioning:
 - Each orchestration instance gets a version permanently associated with it when created.
 - Workers running newer orchestrator versions can continue executing older version instances.
 - 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).
+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
+## Name-based versioning
 
 Define new versions of your functions and leave the old versions in your function app. As you can see in the diagram, a function's version becomes part of its name. Because previous versions of functions are preserved, in-flight orchestration instances can continue to reference them. Meanwhile, requests for new orchestration instances call for the latest version, which your orchestration client function can reference from an app setting.