tag:blogger.com,1999:blog-3840302021974306502.post7185564476527816471..comments2023-10-17T07:09:32.710-07:00Comments on The relative importance of order: RFC: Process deployment use casesHeiko Braunhttp://www.blogger.com/profile/17987290811990461031noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-3840302021974306502.post-34743437506409255072009-04-07T03:13:00.000-07:002009-04-07T03:13:00.000-07:00Maybe I don't understand you correctly, but versio...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.Heiko Braunhttps://www.blogger.com/profile/17987290811990461031noreply@blogger.comtag:blogger.com,1999:blog-3840302021974306502.post-66224818115054337632009-03-26T12:29:00.000-07:002009-03-26T12:29:00.000-07:00Hi,I'd like to put a little comment regarding depl...Hi,<BR/><BR/>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. <BR/><BR/>Will this be addressed in any future release ?<BR/><BR/>Can you respond to this and explain your concerns as well please ?!Heliumhttps://www.blogger.com/profile/01428205088344355783noreply@blogger.com