Proposal: RuntimeService.setProcessDefinitionVersion(pi, pd)

[falko_menge]

We at camunda would like to introduce a method, which changes the process definition version of an existing process instance, to the runtime service.
This method will not perform any migration magic and simply set the process definition version in the database, assuming that the user knows, what he or she is doing.
Of course, this will be carefully documented so that the users know the risks of the operation.

Do you guys have any concerns with such a feature or can we continue with providing an implementation for you to review?

[rvi]

Thanks for reply, I understand your point for keeping it private. I just want to make sure it stays stable and won't be removed or changed without notice.

[…]it's not possible to have two versions of code running for each process version.

One approach, you can also think about, is to use an environment with strong class loader isolation, e.g., an application server or OSGi container, and add a version number to the process definition key. This way you can run multiple versions of a process definition and the code that belongs to it in parallel. The camunda fox Community Edition allows that, too.

yes, i've thought about versioning process definition key for process changes that don't support simple migration.
but I don't see exactly how strong class loader isolation can solve the problem for class version: you would need one activiti engine per process version (in the same classloader as process code) ? what about persistence, would you also need one database per engine ?

thanks
Richard