Skip to content

Add CONTINUE_AS_NEW_VERSIONING_BEHAVIOR_USE_RAMPING_VERSION#2319

Merged
THardy98 merged 7 commits intomainfrom
feat/add-can-ramping-behaviour
Apr 30, 2026
Merged

Add CONTINUE_AS_NEW_VERSIONING_BEHAVIOR_USE_RAMPING_VERSION#2319
THardy98 merged 7 commits intomainfrom
feat/add-can-ramping-behaviour

Conversation

@THardy98
Copy link
Copy Markdown
Contributor

What was changed

DWISOTT - adds UseRampingVersion as a CaN versioning option

Why?

support new versioning option

  1. Part of Expose CONTINUE_AS_NEW_VERSIONING_BEHAVIOR_USE_RAMPING_VERSION in SDKs features#807

  2. How was this tested:
    Added integration tests

  3. Any docs updates needed?
    Maybe ?

@THardy98 THardy98 requested a review from a team as a code owner April 30, 2026 19:12
@THardy98 THardy98 force-pushed the feat/add-can-ramping-behaviour branch from 752ae85 to 7c0781d Compare April 30, 2026 19:15
Comment thread internal/workflow.go Outdated
ContinueAsNewVersioningBehaviorAutoUpgrade = 1

// ContinueAsNewVersioningBehaviorUseRampingVersion - Use the Ramping Version of the workflow's task queue at start time,
// regardless of the workflow's Target Version (according to f(workflow_id, ramp_percentage)). After the first workflow
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

instead of f(workflow_id, ramp_percentage), should we say something along the lines of:

  // The Target Version is chosen with the default formula:
  //   if calcRampThreshold(workflow_id) <= ramp_percentage:
  //     target=ramping_version
  //   else:
  //     target=current_version

I feel like f(workflow_id, ramp_percentage) will invite lots of questions.
I am ok being transparent about this formula -- we won't change it by default after GA because that could cause workflows to "roll back" accidentally, even with same ramp percentage

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

calcRampThreshold is the name of the server function we actually use, so people (or claude) can look it up if they're interested

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm going to remove it entirely, I don't think we need to leak server versioning internals here (I also don't anticipate people finding this particularly necessary)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We define Ramping, Current, and Target version here fwiw https://docs.temporal.io/worker-versioning#versioning-definitions fwiw, so people can look those up there

@THardy98 THardy98 force-pushed the feat/add-can-ramping-behaviour branch from d9f4505 to 9ac729e Compare April 30, 2026 21:58
@THardy98 THardy98 merged commit ebf4b2b into main Apr 30, 2026
62 of 64 checks passed
@THardy98 THardy98 deleted the feat/add-can-ramping-behaviour branch April 30, 2026 22:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants