I’ve read through the various docs on versioning, and it looks to me like a robust versioning framework has been implemented for Workflows. I am trying to find a similar pattern for Activities, but failing.
When running a Workflow, I see that it is possible to specify the version of the workflow to run in the SDK, have multiple workers running on the same task queue with different versions, and the Temporal framework will route the request to the worker on the task queue satisfying the requested version (if available).
For Activities, I only see that the SDK exposes the deprecated flag for a VersioningIntent, but even then, no way to specify the desired version. Similarly, I see no way for the worker to specify its version when registering an Activity. Absent anything in the SDK, I’m thinking the only way to implement versioning for my Activities is to add the semantic version of the Activity to the task queue name. This would result in an explosion of task queues, as well as a somewhat clunky mechanism for Workflows to discover the task queue satisfying the version of the Activity they require. This approach is mentioned in some of the versioning docs, but discouraged in favor of the preferred strategy – which, as far as I can tell, only exists for Workflows.
Is there a recommended approach to versioning Activities? Or are there plans to roll out a similar pattern for Workflow versioning to Activities in a future release? I’m interested to hear how others have solved this problem. And in anticipation of possible replies, I know one approach is to make all Activity code backwards compatible, but this really doesn’t address the problem… if one team builds a Workflow and tests it against a known set of versioned Activity dependencies, they don’t want their Workflow breaking when the behavior of one of those Activity implementations changes later, even if the Activity maintains a backwards-compatible API.
Thanks in advance for any tips!