7 ms·

What considerations do you put into how to handle versioning? I'm thinking mostly of the "decider" logic. For example, in SWF + Flow land, I maintain different

What considerations do you put into how to handle versioning? I'm thinking mostly of the "decider" logic. For example, in SWF + Flow land, I maintain different versions just by keeping the old implementation and using version numbers. For Temporal, your team's recommended way is to have a single decider get the execution's version, and write conditionals into the business logic for both cases (https://docs.temporal.io/docs/java-versioning https://docs.temporal.io/docs/java-versioning). Is the change in approach intentional, or just a matter of what's been built so far?

mfateev 6y ago
The change in approach is intentional. It is still possible to use the old method, but for the majority of cases, it is just too heavyweight. There are two main problems with versioning entire workflows: 1. Need to keep the workers with old code around. It might be solved for some languages like Java by dynamic code loading, but it is still pretty complex. For long-running workflows dozens of changes can happen during their lifetime, requiring dozens of versions to be present at runtime. 2. When a bug is fixed the old versions do not get the fix as they are inherently immutable. Thus a workflow that runs for a month and has started yesterday is still going to experience a bug that was fixed today. The approach that Temporal promotes is to version each piece of code independently when needed. This way, there is only one version of the entire code in production to maintain, and bug fixes can be deployed any time and apply to all the open workflows that didn't reach the code that was fixed.
- nerd_light 6y ago
  Thanks for the reply! My brain got stuck on having to have extended if/else chains if one area changes frequently, but most of our changes are spread out, so fit well with your points. Excited to try it out more!

mfateev 6y ago

The change in approach is intentional. It is still possible to use the old method, but for the majority of cases, it is just too heavyweight. There are two main problems with versioning entire workflows: 1. Need to keep the workers with old code around. It might be solved for some languages like Java by dynamic code loading, but it is still pretty complex. For long-running workflows dozens of changes can happen during their lifetime, requiring dozens of versions to be present at runtime. 2. When a bug is fixed the old versions do not get the fix as they are inherently immutable. Thus a workflow that runs for a month and has started yesterday is still going to experience a bug that was fixed today. The approach that Temporal promotes is to version each piece of code independently when needed. This way, there is only one version of the entire code in production to maintain, and bug fixes can be deployed any time and apply to all the open workflows that didn't reach the code that was fixed.

nerd_light 6y ago
Thanks for the reply! My brain got stuck on having to have extended if/else chains if one area changes frequently, but most of our changes are spread out, so fit well with your points. Excited to try it out more!