Building on what @davidgs said: Zeebe assigns a version number internally, but that is only semantic within the system.
The process id, if you version it, will require a change in your code that starts instances of that process. So you could do that, but it then becomes a cross-cutting concern.
One way to do it is like this:
- Deploy the process model to Zeebe.
- Get the version number that Zeebe returns.
- Add the version number to the XML of the model in a comment.
- Commit this to git.
- Tag the commit with the process id and version.
The relationship between your version controlled asset and the Zeebe version displayed in Operate and used to start instances of that specific version is only created at deployment time - as Zeebe assigns the next sequential version number to the process model when it is deployed.
To capture this relationship in your system of record requires getting the version number at deployment time, and storing it with the corresponding version commit.
Another way to do it, if you wanted to automate this, is to deploy from a specific git branch or tag pattern. Then in the deployment code, grab the version commit hash that is being deployed, and the version returned from the DeployProcess command, and write that to your system of record.