Since 4.0.0.Beta1
- What deployment use cases do we want to cover?
- What constraints should apply for each use case?
The matrix below shows the constraints for the deployment policies that are currently implemented:
Explanation:
There is currently four properties that are taken into consideration when processes get deployed:
the process name and version (part of jpdl.xml), the artifact name (i.e OrderProcess.par) and the artifact timestamp.
Process name, version and artifact name are the main properties that distinguish process deplyoments, the timestamp basically just acts as a fallback when no version is given and leads a version auto-increment.
Possible combinations of those properties lead to matrix above.
2 comments:
Hi,
I'd like to put a little comment regarding deployment of a process. My big concern is with updates to current processes. There sure will be enhancements and bug fixes to any deployed process. However as per current state of jBPM, there is no way to replace a process with a new version. That is a big drawback for me, because our processes can evolve and change, and we do not want to keep instances running the old process version.
Will this be addressed in any future release ?
Can you respond to this and explain your concerns as well please ?!
Maybe I don't understand you correctly, but versioning does already exist in jBPM3. jBPM4 does implicitly increment a process version when a process is deployed again. Alternatively you may explicitly set a process version in jpdl.
Post a Comment