Add one-time move to the versioning override API!

[Shivs11]

What changed?

• WISOTT

Why?

• So that operators can have a versioning override that is not sticky. The idea is that the next task of the workflow execution moves to the target version, after which the behaviour/version of the workflow are dictated by the worker response.

Breaking changes

• No, since this is a new option that I am adding whose default value is false (it's opt-in)

Server PR

• in progress

[yiminc]

so this would continue to be sticky pin behavior? I think we need to update the doc so it is more clear. It would ignore even when SDK do CAN and wants change to AU to current version?

[Shivs11]

It would ignore even when SDK do CAN and wants change to AU to current version

yes, the PinnedOverride is meant to be sticky. As long as it exists on a workflow execution, it shall be pinned to a specific workflow execution

[rkannan82]

I have given this naming some more thought. What do you think about?

• MoveAndKeepDefaultBehavior: this clearly tells the behavior. move to version X, then respect whatever is the default versioning configuration defined in code. It tells this is not sticky unlike PinnedOverride where it moves to version X and stays put.

• Also add the following to the comment:
  When you moves the wf from version x to y, and a new version z arrives.

  • if a workflow is pinned, it will stay on the y
  • if wf is auto upgrade -- it will move to z
  • if wf uses upgrade on can -- it will move to z when can happens

• Personally, I would avoid using temporary.