Just wanted to give you guys an early update. I encountered a significant unexpected issue. It was related to updating the classloading. Due to updates in classloading, I came to change the jPDL parsing. the occasion here is minor: i want to refactor the expr attribute to object-expr in user code declarations. but the implications seem to be hard. Then I realized that the old (v4.0 and v4.1) process files are in the DB. For users that want to upgrade, this parser change potentially breaks existing installations in a non-recoverable manner as the new parser might not parse the existing deployed process definitions in the same way. (the XML is stored in the DB) The solution I'm currently targetting for is pretty involved: * Each release will have its own namespace URI. (i forgot this in 4.1. so release 4.1 still contains the 4.0 namespace) * Each version of jPDL will add it's own parser. All old parsers will be kept in the codebase as well. So that jBPM can still deploy older process versions that are deployed and stored in the DB. * Each time when a process is deployed, the optional namespace declaration is checked. If not present, the jPDL version deployer will add the namespace and re-serialize the process xml in the deployment that will be stored in the DB. That way the deployed process in the DB will contain the version explicitly of the process XML. And later, each time when jBPM parses that process file after a reboot, then the correct parser associated with that jPDL version can be used. * So users should still be able to deploy e.g. a jPDL process in version 4.3 XML in jBPM version 4.7 * Migration tool will apply the namespace check and add the 4.0 namespace. * For testing, I think it is sufficient to use a single test suite. When we embark on a new version, the full test suite will be using the new version's parser. The old version's parser will not be changed any more. So that is why I think it is ok if it is not tested any more. from a first glance, this seens to be the only way in which we can support decent backwards compatibility and still allow us to evolve the language. thoughts ? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258277#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...