"kukeltje" wrote : Ok, the 'parking' of older parsers makes sense. I do have som questions though | - A version is not only the parser but also accompanying activity implementations. These are instantiated once a process is started (from what I understand). Does this have implications? | very true ! that's the tricky thing i ran into yesterday. so now i think we should aim for the following approach: * make sure that we can know the version of each process when we parse it. this can be a bit tricky, because 1) we do not enforce people to specify namespace, so when deploying a process, the current library version somehow has to be added in to the db. and another issue is this: if we use the namespace for knowing the version, then this is also used to activate or not activate the xml validation. so we could end up with the situation that an invalid process deploys because originally the namespace was not present. if we then add the namespace before we save it in the deployment, then when loading it from the db it contains the namespace and that will activate validation. and hence the process can not be used. given that we use a cache after deployment, this kind of problem might not show up in test environments. * introduce a couple of if-then-else statements in the parser that depend on the version * the hard part is testing. i'm still trying to find how to we test this? how can we make sure that old deployed processes will still work correctly in newer versions of jBPM. i've been thinking about making sure that we run the test suite with a version parameter. then all the processes in the testsuite which don't have an explicit namespace, will use the configured parser version. but i'm not yet sure if this tests what we actually need. and to what extend it protects us from making backwards incompatible changes. if we get this wrong, the risk is that we break existing installations after they upgrade. "kukeltje" wrote : - Currently the schema is not fully 'any:any' aware. (I still think it should be 'other:any' for the extensibility. Fully supporting this is needed if you automatically want to add a namespace since people can remove the ns now if they want to add custom attributes. | if you declare extensibility with any:any, then users can *still* define all their extensions in their own namespace. they are just not forced to do it if they want to. why do think users *need* to define their extensions in a separate namespace. i agree that it would be good practice from a user perspective. but i don't see a reason why we should enforce our users to it like that. "kukeltje" wrote : - Does this mean that people have to redeploy their old processes if they want to take advantage of certain bugfixes in e.g. activity implementations? that's the kind of questions that we have to ask ourselves when composing a solution. i didn't yet see the best solution for this whole compatibility and versioning of deployed processes issue. but my neural network is chewing on this with 100% CPU utilization. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258532#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...