I can see in the go-client versioning documentation Versioning | Temporal, 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?