"brittm" wrote : Of course, you would have to implement code to reject re-deployment of a process definition that tried to deploy with a version number that was already in use for that definition name, | or even more strickt: the given version number has to match exactly with the expected version number, which is the previous highest version + 1 the motivation for this is auto deployment. if we have such a mechanism, then you can drop your processes in a deploy folder. a deployer can then figure out if the process needs to be redeployed or not. it also keeps the developer in charge of whether he wants to redeploy or not. the designer tool could offer convenience for this by incrementing the version in the source file automatically each time when you deploy. i'm still not totally clear on how to deal with multiple staging environments. where you want to just deploy like we do now in development, but you want the verified deployment in production. a potential solution might be the deployment interceptors that i've just worked out. (a more generic variant of the configurable parser sequence that we have now in jbpm 3). i have one interceptor that does the validation and that one is configured in the configuration file. so if in development you don't want that validation, then you just remove that line in the environment configuration. anyways, all these are many ideas that didn't result into a clean picture for me. so all input like this is certainly welcome. "brittm" wrote : I suppose we're really talking about two different things: the jBPM version_ field is versioning deployments, whereas the developer is versioning content. those two are related. and it's infact that relation that is not always clear. britt, can you ping me in another email. i tried to email you and i got a failure on your account. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4149328#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...