Sure: there are a few options here as how to handle the 'previous' process definition (more specifically what the upgradeProcessInstanceDefinitionVersion() method does):
- Overwite the existing process definition and set the process instance to this one. In this case the change must be possible, as in there must exist a matching element in both process definition
- Explicitely map. Do a mapping from activities to the new activities (A->A, B->C, etc)
Which is clear, I think. But there are now two deployments, in both cases, and this needs to be reflected in the audit history too.
So my comment was more referring to that: how would the 'dynamicity' be captured, both in runtime and history.
But both options are born from the fact that deployments and process definitions are static in Activiti (and rightly so, for performance reasons). I wonder if there are different mechanisms possible … where that is not needed, and where the process definition is really fluid … but that would mean a different implementation of some of the core parts … or maybe not.
Stuff to think about!
