The versioning of Processes and Subprocesses are technically identical and should have the same common best practices. Still, the developers need to keep in mind that a Process could have external consumers via HTTP/API Triggers so the versioning needs to be communicated to the stakeholders too, whereas Subprocesses are only invoked by other Processes or Subprocesses.

In the picture above there is a Process Settings Panel showing that the Major version and Minor version are input fields meaning they can be changed in Frends. As Frends automatically increments the Build number on every save, the developers are not able to affect it.

It is suggested to follow the general guidelines of semantic versioning for changing the Major version which states that the Major version should be incremented when there is a backwards incompatible update for a Process or Subprocess. This means that the dependencies to other systems or software will most likely break and therefore require updates too.

For example, if an HTTP Trigger in a Process requires a new type of payload or header, before saving the Process and incrementing the Build number automatically, the developer needs to at least increment the Major version and communicate this change to the relevant stakeholders.

As with the Major version, it is also suggested to follow the general guideline of semantic versioning with the Minor version. The Minor version needs to be incremented when the change only affects the internal functionality and the Process or Subprocess is still backwards compatible.

For example, if a Process' internal logic is updated to be more efficient and requires no change from the connections or dependencies it is using, the Minor version needs to be incremented.

The next article is Best practices on Versioning of APIs