Hi @jbrody
I’m one of the developers of worker versioning. If I understand correctly, it sounds like your goal here is to version your Activities and Workflows separately because they have separate release schedules.
This is currently supported by Worker Deployments, in that Activity Task Queues / Activity-only workers and Workflow Task Queues / Workflow-only workers can be part of separate Worker Deployments.
For example, when your Activity code is ready to be released, you could deploy an Activity-only worker with DeploymentName=”my-activity-deployment” and BuildID=”xyz” polling on TaskQueue=”my-task-queue". This will create an Activity Task Queue named “my-task-queue” that is a part of the Worker Deployment “my-activity-deployment”. If you then ramp traffic to and eventually set current BuildID “xyz” on Worker Deployment “my-activity-deployment”, all tasks on that Activity Task Queue will go to Activity workers with BuildID “xyz”.
At some other time, when your Workflow code is ready to be released, you can deploy a Workflow-only worker with DeploymentName=”my-workflow-deployment” and BuildID=”abc” (technically you could give it the same build id, but that might be confusing). You could let that Workflow-worker poll on TaskQueue=”my-task-queue” (or a different name), which will create a Workflow Task Queue that is part of the Worker Deployment “my-workflow-deployment”. Same as above, if you then set BuildID “abc” as the current version of Worker Deployment “my-workflow-deployment”, all tasks on your Workflow Task Queue will go to Workflow workers with BuildID “abc”.
If you do things this way, you’ll need to be mindful of keeping Activity-interface compatibility between the workflow and activity definitions that are being used together at the same time.
Please let me know if this setup does not address your use-case!
Best,
Carly