Add author tags, update ToC

Signed-off-by: Hal Spang <[email protected]>

Author: halspang

articles/azure-functions/durable/TOC.yml

@@ -124,8 +124,6 @@
     href: ./durable-task-scheduler/durable-task-scheduler-dashboard.md
   - name: Auto-purge 
     href: ./durable-task-scheduler/durable-task-scheduler-auto-purge.md
-  - name: Versioning
-    href: ./durable-task-scheduler/durable-task-scheduler-versioning.md
   - name: Durable Functions
     items:
       - name: Throughput benchmark
@@ -136,6 +134,8 @@
     items:
     - name: Configure autoscale for Azure Container Apps hosting
       href: ./durable-task-scheduler/durable-task-scheduler-auto-scaling.md
+    - name: Versioning
+      href: ./durable-task-scheduler/durable-task-scheduler-versioning.md
   - name: Billing
     href: ./durable-task-scheduler/durable-task-scheduler-dedicated-sku.md
   - name: Troubleshoot

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

@@ -3,14 +3,16 @@ title: Configure Versioning for Durable Task Scheduler (preview)
 description: Learn how to use orchestration versioning in Durable Task Scheduler.
 ms.topic: how-to
 ms.date: 07/16/2025
+author: halspang
+ms.author: azfuncdf
 zone_pivot_groups: df-languages
 ---
 
 # Orchestration Versioning
 
-A key area to consider when using a durable orchestration system is how to handle the upgrading/downgrading of orchestrations. When an orchestration is interrupted and later resumed (for instance, during a host update), Durable Task Scheduler will replay the events of the orchestration. This is done to ensure that the orchestration executes the same steps each time which is a core promise of the durable execution paradigm. So, if an orchestration changes between deployments, the steps it takes may no longer be the same. If this does happen, the system will provide a `NonDeterministicError` instead of allowing the orchestration to continue. 
+A key area to consider when using a durable orchestration system is how to handle the upgrading/downgrading of orchestrations. When an orchestration is interrupted and later resumed (for instance, during a host update), Durable Task Scheduler will replay the events of the orchestration. This is done to ensure reliability - the system replays to ensure all previous steps were executed successfully before the next step is taken - which is a core promise of the durable execution paradigm. So, if an orchestration changes between deployments, the steps it takes may no longer be the same. If this does happen, the system will throw a `NonDeterministicError` instead of allowing the orchestration to continue. 
 
-Now, with orchestration versioning, there is a way to prevent this and work seamlessly with new (or old) orchestrations. Durable Task Scheduler has two different styles of versioning which will be explored below. Note that the different versioning styles can be used separately or together.
+Orchestration versioning helps to prevent problems related to non-determinism, allowing you to work seamlessly with new (or old) orchestrations. Durable Task Scheduler has two different styles of versioning which will be explored below. Note that the different versioning styles can be used separately or together.
 
 ::: zone pivot="javascript"
 
@@ -27,20 +29,23 @@ Now, with orchestration versioning, there is a way to prevent this and work seam
 ::: zone pivot="python"
 
 > [!IMPORTANT]
-> Currently, versioning is not available in the Python SDK.
+> Currently, versioning isn't available in the Python SDK.
 
 ::: zone-end
 
 ::: zone pivot="csharp,java"
 
-## Client/Context Based Conditional Versioning
+## Client/context-based conditional versioning
 
-In order for an orchestration to have a version, it must first be set in the client. For the .NET SDK, this is done through the standard host builder extensions, as seeen below:
+In order for an orchestration to have a version, it must first be set in the client. For the .NET SDK, this is done through the standard host builder extensions, as seen below:
 
 ::: zone-end
 
 ::: zone pivot="csharp"
 
+> [!NOTE]
+> Available in the .NET SDK since v1.9.0.
+
 ```csharp
 builder.Services.AddDurableTaskClient(builder =>
 {
@@ -53,6 +58,9 @@ builder.Services.AddDurableTaskClient(builder =>
 
 ::: zone pivot="java"
 
+> [!NOTE]
+> Available in the Java SDK since v1.6.0.
+
 ```java
 public DurableTaskClient durableTaskClient(DurableTaskProperties properties) {
     // Create client using Azure-managed extensions
@@ -66,9 +74,9 @@ public DurableTaskClient durableTaskClient(DurableTaskProperties properties) {
 
 ::: zone pivot="csharp,java"
 
-Once that is added, any orchestration started by this host will use the version `1.0.0`. The version itself is a simple string and accepts any value. However, the SDK will try and convert it to .NET's `System.Version`. If it can be converted, that library is used for comparison, if not, a simple string comparison is used.
+Once that is added, any orchestration started by this host will use the version `1.0.0`. The version itself is a simple string and accepts any value. However, the SDK will try to convert it to .NET's `System.Version`. If it can be converted, that library is used for comparison, if not, a simple string comparison is used.
 
-By supplying the version in the client, it also becomes available in the `TaskOrchestrationContext`. This means the version can be used in conditional statements. So, as long as newer versions of an orchestration have the appropriate version gating, both the old and the new version so of the orchestration can run together on the same host. An example of how the version can be used can be seen below:
+By supplying the version in the client, it also becomes available in the `TaskOrchestrationContext`. This means the version can be used in conditional statements. So long as newer versions of an orchestration have the appropriate version gating, both the old and the new version of the orchestration can run together on the same host. An example of how the version can be used is:
 
 ::: zone-end
 
@@ -124,24 +132,24 @@ public TaskOrchestration create() {
 
 In this example, we've added a `SayGoodbye` activity to the `HelloCities` orchestration. This is only called if the orchestration is at least version `2.0.0`. With the simple conditional statement, any orchestration with a version less than `2.0.0` will continue to function and any new orchestration will have the new activity in it.
 
-### When to Use Client Versioning
+### When to use client versioning
 
 Client versioning provides the simplest mechanism for versioning orchestrations, but interacting with the version is also the most programming intensive. Essentially, the two functionalities that client versioning provides are the ability to set a version for all orchestrations and the ability to programmatically handle the version in the orchestration. It should be used if a standard version is desired across all versions or if custom logic around specific versions is required. 
 
-## Worker Based Versioning
+## Worker-based versioning
 
-An additional strategy that can be used for handling versions is setting up worker versioning. Orchestrations will still need a client version in order to have the version set, but this method allows the user to avoid conditionals in their orchestrations. Worker versioning allows the worker itself to choose how to act on different version so of orchestrations before those orchestrations start executing. Worker versioning has several fields to set, which are detailed below:
+An additional strategy that can be used for handling versions is setting up worker versioning. Orchestrations will still need a client version in order to have the version set, but this method allows the user to avoid conditionals in their orchestrations. Worker versioning allows the worker itself to choose how to act on different version of orchestrations before those orchestrations start executing. Worker versioning requires the following fields to be set:
 
 1. The version of the worker itself
-2. The default version that will be applied to sub-orchestrations started by the worker
+2. The default version that will be applied to suborchestrations started by the worker
 3. The strategy that the worker will use to match against the orchestration's version
-4. The strategy that the worker should take if the version does not meet the matching strategy
+4. The strategy that the worker should take if the version doesn't meet the matching strategy
 
 The different match strategies are as follows:
 
 | Name           | Description                                                                              |
 |----------------|------------------------------------------------------------------------------------------|
-| None           | The version is not considered when work is being processed                               |
+| None           | The version isn't considered when work is being processed                                |
 | Strict         | The version in the orchestration and the worker must match exactly                       |
 | CurrentOrOlder | The version in the orchestration must be equal to or less than the version in the worker |
 
@@ -225,12 +233,12 @@ private static DurableTaskGrpcWorker createTaskHubServer() {
 
 ::: zone pivot="csharp,java"
 
-The `Reject` failure strategy should be used when the desired behavior is to have the orchestration try again at a later time/on a different worker. When an orchestration is rejected, it is simply returned to the work queue. When it is dequeued again, it could land on a different worker or the same one again. The process will repeat until a worker that can actually handle the orchestration is available. This strategy allows for the seamless handling of deployments in which an orchestration is updated. As the deployment progresses, workers that cannot handle the orchestration will reject it while workers that can handle it will. The ability to have mixed workers/orchestration versions allows for scenarios like blue-green deployments.
+The `Reject` failure strategy should be used when the desired behavior is to have the orchestration try again at a later time/on a different worker. When an orchestration is rejected, it's simply returned to the work queue. When it's dequeued again, it could land on a different worker or the same one again. The process will repeat until a worker that can actually handle the orchestration is available. This strategy allows for the seamless handling of deployments in which an orchestration is updated. As the deployment progresses, workers that can't handle the orchestration will reject it while workers that can handle it will process it. The ability to have mixed workers/orchestration versions allows for scenarios like blue-green deployments.
 
-The `Fail` failure strategy should be used when no other versions are expected. In this case, the new version is an anomoly and no worker should even attempt to work on it. So, the Durable Task Scheduler will fail the orchestration, putting it in a terminal state.
+The `Fail` failure strategy should be used when no other versions are expected. In this case, the new version is an anomaly and no worker should even attempt to work on it. So, the Durable Task Scheduler will fail the orchestration, putting it in a terminal state.
 
 ### When to Use Worker Versioning
 
-Worker versioning should be used in instances where the desired reaction for an orchestration of an unknown or unsupported version should not be worked on at all. Instead of placing version handling code in the worker, worker versioning stops the orchestration from ever executing. This allows for much simpler code in the orchestrations themselves. Without any code changes to them, various deployment scenarios can be handled, like blue-green deployments mentioned before.
+Worker versioning should be used in scenarios where orchestrations of an unknown or unsupported version shouldn't be executed at all. Instead of placing version handling code in the worker, worker versioning stops the orchestration from ever executing. This allows for much simpler orchestration code. Without any code changes, various deployment scenarios can be handled, like blue-green deployments mentioned before.
 
 ::: zone-end