Process Versioning Strategy

Anyone have writeup or thoughts on Process Versioning strategies?

Does something like http://semver.org easily apply to Processes? Areas where it would not apply well? Any thinking on what would be considered a Major version number change vs a minor?

Thanks!

Hi,

actually adding the version tag already helps. You can decide what strategy to follow depending on the use cases.
We still add a number (following the semver) to the display name of a process definition. Reason: In communication with users starting instances from task list, we need to have the version to easily report on in case of issues.

We use it this (kind of the standard) way:
major: other depending workflows need to have the same major version as communication between them needed to change due to new/changed functionality. Our definitions need to run the same major version. Needs careful prep and roll-out like every API change in all areas basically.
minor: Added functionality, no impact on depending definitions
patch: only fixes, no functionality changed

Werner

@wke-rec so you only change the Major version number if other processes are impacted? Otherwise it is a Minor version change?

Yes, this is equal to a new API version potentially including breaking API changes. Dependent process definitions with different major versions must not call each other but upgraded together. While minor version changes still can be done per each process definition without touching others as they must be compatible.

Thanks,
Werner

@wke-rec if we assume no changes or impacts are made to systems that inspect the process during execution or systems that get contacted by the process during execution, would you see any scenarios where the major version would be changed?

There could be significant changes to a process without the Inputs or outputs of the process changing. For example if there were multiple user tasks added and changed, but these user tasks did not have impact other processes or system interactions, would you still see that as minor version change?

Breaking changes might at the end not be the only reason to do a major version bump. Significantly changed functionality can also lead to major version changes. But in this case it is not a must but more part of the communication/marketing strategy.

Great.
Thanks @wke-rec