As it stands, workflow versioning looks hard and messy ( sorry ).
Each time you change the workflow, you need to create a workflow that essentially contains code for old workflow and the new one separated with a series of if() conditions .
Why wasn’t Temporal designed so that newWorker has an extra argument which acts as the version
Worker worker = factory.newWorker(TASK_QUEUE,1); //version 1. This worker will only pick up tasks from TASK_QUEUE if their version is 1
Multiple workers in multiple processes/JVMs can run at the same time. each will be self-sufficient and independent. Each will be oblivious about the existence of other version workflows with different logic.
( This is what some other Orchestration Engines like Activevos do )
( Or did I understand the Temporal versioning mechanism incorrectly? )
There are a few issues with the way other orchestration engines do versioning when applied to Temporal.
It is not possible to patch an already running workflow. For example, a workflow that lasts three months and has a bug at the end. Even if a fix is deployed, all workflows that started for the last three months are still going to experience the bug.
Temporal workflows are complex programs that can consist of multiple classes and include class libraries written by others. Two versions of the same workflow loaded into the same process cannot reference different library versions without mechanisms like class loading.
Running each version in its own process works, but it can quickly become an issue for long-running workflows, which can have dozens of changes during a single workflow lifetime.
We plan to add the whole workflow versioning to languages like Java and Typescript that support bundling all the code and loading it independently for each version. Even for these languages we still will keep the current mechanism as an ability to patch already running workflows is essential for most users.
Regarding this planned feature : Are you talking about Java 9 modules with layers ( uses separate class loaders ) ?
This will mean you will run code for multiple versions under the same Jvm
( note passing version as an extra argument like I mentioned earlier requires multiple jvms )
Regarding this planned feature : Are you talking about Java 9 modules with layers ( uses separate class loaders ) ?
It is not designed yet. I know that even in the older version of Java you could use class loaders to achieve this. I believe the Typescript SDK will be the first one to support such features.