I read the doc on versioning and just wanted to get clarification. In the following cases, versioning needs to be done:
if the workflow or activity name changes or if the function signature changes.
if the activity passes a struct and the struct change we don’t really need to worry about versioning since calls to the activity is non-deterministic
If the workflow passes a struct and the struct change, versioning has to be applied. In the case of a parent workflow calling the child workflow, If the struct is still backward compatible (ex. proto generated), versioning only has to be done in the child workflow with the updated fields in the struct. no versioning needs to be done at the parent level.
I’m trying to figure the best way to handle versioning. It’s becoming a pain point to apply versioning whenever I need to update a workflow or activity name or signature. I’ve had to create v2 of the methods until the existing workflows have completed and the retention of them have expired.
if the workflow or activity name changes or if the function signature changes.
Changing activity type would need to be versioned. Changing the workflow type and registering it with worker under this new type would mean worker would no longer be able to process executions clients might start for the old type.
Don’t think that function signature changes need to be versioned. Just note that activity inputs are recorded in event history so if you make this change while an activity is retrying, the originally recorded inputs would apply for each retry which can cause issues. Using single object type/struct for inputs can solve this, just make sure your activity code can support the “old” and “new” signatures until you are sure there are no pending activities with the old signature.
if the activity passes a struct and the struct change we don’t really need to worry about versioning since calls to the activity is non-deterministic
Similar to above, using struct can help with updating fields without worrying about order of function arguments. Similar applies to the third question related to workflow/child workflow input as well.