In jBPM4.4 you can deploy a jPDL with the same name multiple times. The different versions automatically get a different version number and processInstances will keep using the version that was current when the processInstance started.
You do not need to select specified Process Definitions upon engine startup. All is retrieved from the database as needed.
In jBPM5.4 things seem to be different. If I am correct the Knowledge base needs to be filled at startup with all Process Definitions which are needed by any running process.
If I need multiple versions of the same Process Definition in the kBase to complete process instances started with a different version, it seems I cannot use the same id for the different "versions" of the "same" process definition.
Adding two process definitions with the same id but a different version number does not seem to work.
1) Am I right so far?
that is correct, you cannot have same process id for different process definitions within same kbase. If you try to do that one will override the other and the order of override will be same as the order of adding resources to knowledge base.
If (1) == yes then
2) what it the use of the version number?
you can still use version number as part of the runtime, so the scenario is:
- create process definition with id abc, name process1 and version 1
- create process definition with id abcd, name process1, version 2
with that you can have both versions running in the same kbase and ksession as the ids are unique. Then you can use some helper classes to start process by name that will take into account the version number and ensure that the latest version will be used. See this helper class for details
3) will everything work if I change the ProcessDefinitions with as id the original processDefinition id concattenated with the version number?
it will work fine as long as you have them separated. Consider case that you model process version 1 deploy it to runtime start process of it and then you go and change the exact same process definition that will cause the situation where new process definition will be replaced. Most important piece of information is when you do new version of the process make a copy of the origin process def and work on the copy to produce new version, don't change the existing one as it will impact currently running instances of that process id.
4) does Guvnor support automatic version management?: create BPMN with id a.b.c , start processInstance for this BPMN, change BPMN (keep id, but increment version), start second processInstance. ProcessInstance 1 will keep using version 1 of BPMN, ProcessInstance 2 will use the updated version of the BPMN
see comment above. And in general, Guvnor is authoring tool based on JCR so it does support versioning of assets it maintains, but it's not the same versioning you have in mind. It keeps versions of the asset modifications, like history of what has changed and when, etc. It does not affect the runtime engine. To keep the isolation between running instances and version of the process make sure that you have process definition versions in separate files, that way all will work properly as it will be able to refer to the version it needs
If (4) == no then how does Guvnor handle changes to BPMN definitions?
Are you supposed to upgrade all running versions of a Process Definition?
Again Guvnor does not deal with it, there is KnowledgeAgent that transfers the build packages to runtime environment as soon as they are ready to update the kbase in the runtime. With that all rules given above apply and might be that you would need to upgrade the process instance if that is the strategy you have chosen - for example you need to change given version of the process definition instead of creating new one.