I know the process definitions complete at their current version, but our application code changes over time. A good example of this is form processing for a new Task definition in a parent process definition. The application code must change to process the Task, but previous incarnations of the process definition (and application code) didn't have the task/processing defined.
Two ideas come to mind for this.
One is you can have your application code do a check on the process definition version. So when you release new Grails code you can have that Grails code be aware of which version of the process a particular task belongs to.
Another approach is when you upgrade the Grails app you also migrate all of the existing process instances to the new version. That may be easier or more difficult depending upon what specifically is changed. Actually there are at least two sub-options within this (both listed in Process Instance migration ). You could programmatically update the old process definition by looking it up through the repositoryService and applying changes, which would immediately apply to all the running instances but can be tricky code to write depending upon the changes to the model. Or you can programmatically close the exiting instances and create new ones that 'match' them, porting across the values of the variables and moving them through state if needed. I think there is actually a third option, which is to use an Activiti feature to migrate but that comes with disclaimers as again it depends on the process definition whether it will work for you - see There are a motive for not exist a exposed API for 'SetProcessDefinitionVersionCmd' ? and Process instances migration
