I can see in the go-client versioning documentation Versioning | Temporal Documentation, it is mentioned “However, if you want your currently running Workflows to proceed based on the current Workflow logic, but you want to ensure new Workflows are running on new logic, you can define your Workflow as a new WorkflowType , and change your start path (calls to StartWorkflow() ) to start the new Workflow type.”
Can you explain how to achieve this versioning by defining new WorkflowType and changing start path?
Any examples to do that?
More questions related to same:
If I have a usecase where there is slight change between 2 workflows and I want to slowly remove the 1st workflow but not based on whether an existing workflow runId is executing an older version of code. It would be on the need basis if I can execute 1st workflow version or 2nd workflow version. I may continue to use old version and for a specific usecase I will execute 2nd version. Can you help me if I can achieve this by different WorkflowType or getVersion method ?
If I want to use getVersion call to handle versioning of old v/s new code in different staging environments like Dev, QA, Production. My code goes into QA often but goes into production every 1 month, how to handle different versioning in different environments?
Eg: In QA, I have 4 versions of code handled by getVersion & if else block but production has only 1. Also, in QA I found that only 4th version is suitable for production. How should I proceed with my deployment into production?
If I change an activity without changing parameters, do I need to use getVersion api ? Will the existing workflow runId still execute old activity or it will automatically identify change in activity and run that? What should be done if I still want to use older definition or I just want to use newer definition?
Can we do any versioning at Activity level?
Apart from getVersion and WorkflowType way of versioning, is there any better way to do versioning of workflows?
Can you explain how to achieve this versioning by defining new WorkflowType and changing start path? Any examples to do that?
You use different workflow type (different function name) for each version. So if your workflow was
func MyWorkflowV1(...) ...`
It becomes
func MyWorkflowV2(...) ...`
The code that starts the workflow should be also updated to call into the new version.
If I have a usecase where there is slight change between 2 workflows and I want to slowly remove the 1st workflow but not based on whether an existing workflow runId is executing an older version of code. It would be on the need basis if I can execute 1st workflow version or 2nd workflow version. I may continue to use old version and for a specific usecase I will execute 2nd version. Can you help me if I can achieve this by different WorkflowType or getVersion method ?
I would use different workflow types (if hosted in a same worker process) or different task queues if the versions are hosted by different worker processes.
If I want to use getVersion call to handle versioning of old v/s new code in different staging environments like Dev, QA, Production. My code goes into QA often but goes into production every 1 month, how to handle different versioning in different environments?
Eg: In QA, I have 4 versions of code handled by getVersion & if else block but production has only 1. Also, in QA I found that only 4th version is suitable for production. How should I proceed with my deployment into production?
The newly executed code always takes a branch with the maximum version. So if a production code is running version 1 and new code has versions 1-4. The production code will end up with versions 1 and 4 only. So if you are 100% sure that production has version 1 only then you can remove all the intermediate versions from your code, but it is not needed.
If I change an activity without changing parameters, do I need to use getVersion api ? Will the existing workflow runId still execute old activity or it will automatically identify change in activity and run that? What should be done if I still want to use older definition or I just want to use newer definition?
Activities are stateless. So you can change their implementation any time. As the service has a single implementation of an activity it is going to call whatever version it is linked to.
Can we do any versioning at Activity level?
I don’t understand the question. Activity implementation doesn’t need to be versioned. But keeping it backward compatible is a good idea.
Apart from getVersion and WorkflowType way of versioning, is there any better way to do versioning of workflows?
I recommend always using getVersion. It is not the prettiest mechanism, but it works reliably.
If I change an activity without changing parameters, do I need to use getVersion api ? Will the existing workflow runId still execute old activity or it will automatically identify change in activity and run that? What should be done if I still want to use older definition or I just want to use newer definition?
Activities are stateless. So you can change their implementation any time. As the service has a single implementation of an activity it is going to call whatever version it is linked to
So, does it mean that whether I call getVersion api from workflow or not, the latest implementation will be picked by workflow?
Workflow doesn’t know anything about activity implementation as it can reside in a different process. It invokes it by activity type and task queue names and passes arguments in a serialized format.
So workflow doesn’t really pick activity implementation. An activity worker receives an activity task that contains an activity type name and arguments and dispatches it to an implementation. Only one implementation of an activity type is supported per activity worker.