anonymous wrote : jBPM does *not* do this. The application (or framework) does I was responding to argo's issue, rather than your previous post. Sorry I wasn't clear about that. Versioning... jBPM's current version scheme does a great job for what it is intended to within the jBPM library; however, from an administrative perspective there are three pieces of info that a developer or admin are very interested in having regarding every ProcessDefinition deployment: * Which version of UI requirements are needed, if any. * When was the Definition deployed (this simple timestamp can answer a lot of questions very quickly). * Is this a major release that breaks compatibility, or is it a minor release that simply addresses a small bug, typo, etc. These three pieces of info are pretty important for management of a large application--and they are simple--just three fields that ought to live on the ProcessDefinition itself. The developer can apply any standard for versioning and can use the data any way he sees fit. <processdefinition name='myDef' release='1.12.4' ui='1.8' > Since the meta data is purely user supplied and user consumed, jBPM should not bother with any type of comparison or validation. It just needs to store it. No compatibility issues. On the topic of UI requirements: Two types of screen requirement versioning are appropriate--one at the process level for summary screens, and one at the task level for task screens. So, we would also apply ui= to the task entry as well: <task name='myTask' ui='1.9'> ProcessDefinition ui= can be used to apply screen requirement versioning to process summary screens, or to apply screen versioning to tasks across the board. Task ui= can be used to apply screen requirement versioning on a task by task basis if that level of detail is desirable. This solution would provide a needed mapping in a place where it is easiest to apply and use, and still keeps UI concerns at arms length from the process defintion. We're only acknowledging that there is a UI requirement for this process/task and referencing that requirement at the highest level. When the solution can be so simple, it seems a shame to not provide for a user request that has become so common. If this is a lowest-common-denominator solution that doesn't raise major objections, I'll create a JIRA issue for it. I may also be able to provide an implementation if my current schedule permits, but that's not a promise. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124212#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...