Ronald, 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, but other scenarios would require some thought--would you stop deployment of a definition just because its version number is lower than the greatest currently deployed version? (someone might intentionally want to re-deploy and use an earlier release. Then, how would jBPM know that the earlier release number is the definition it should be using?) Personally, I think its cleaner, safer, and more flexible to just let jBPM continue managing the version_ field itself, and give the developer a separate field to version their process definition's content. I suppose we're really talking about two different things: the jBPM version_ field is versioning deployments, whereas the developer is versioning content. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4149288#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...