Enforce semver format for `version`

[JBBianchi]

What would you like to be added:
The version of a workflow definition can be any string. Enforcing semver should be considerated.

Why is this needed:
In my understanding, the version is used to distinguish different iterations of a said workflow. For instance, a user creates a workflow named Beautiful Workflow. After some time, something needs to be changed for whatever reason. The user updates the Beautiful Workflow. There are two versions of the same workflow living side by side, for instance 1.0.0 and 1.1.0.
Currently, a version could be anything, a user could deploy workflows such as { "name": "pokemon", "version": "red" } and { "name": "pokemon", "version": "blue" }. I'm not sure that it's an intended use of this field.

WDYT ?

[tsurdilo]

Hey, remember we had these discussions before and ended up with not enforcing a particular versioning style.
Worth discussing again so lets get everyones opinions here.

[JBBianchi]

Sorry if I'm bringing back a dead thread, feel free to close the issue. Your take on it @tsurdilo is to have "free" version?

[tsurdilo]

Let's keep it open to gather peoples opinions as it might be relevant.
At the time we discussed it some users mentioned they have very customized versioning needs and said enforcing would not fit their use case, thats why I remember we did not enforce (I was fan of semver too by the way :) )

[tsurdilo]

Here is a comment I made on an old issue from last year:

"The idea in the text is that if you use a standard such as SemVer rather than some custom versioning scheme, there is a higher probability chance it will be supported by more runtimes"

[tsurdilo]

It's also mentioned in spec documentation in this section: https://github.com/serverlessworkflow/specification/blob/main/specification.md#workflow-versioning

[ricardozanini]

Agreed to keep an open string. IMHO, there's no strong reason for the spec to enforce such a pattern.

[cdavernas]

@ricardozanini IMHO there's a strong need to enforce semver: cross compatibility across runtimes, which is what SW aims for. Otherwise, as Jb said, it's gonna be a total chaos, with people using any kind of format, whereas semver is de facto used everywhere in IT

[ricardozanini]

Not sure. On Kubernetes, for instance, they use v1, v1alpha1, and so on. Each user might have a way of setting up versions. I've seen things like 20220922 or even branch naming. I'd let the conventions be for users.

[cdavernas]

Bad example: K8s uses semver ;) (like github, gitlab, knative, argo, etc.)And versions you supplied are valid semver suffixes.

[ricardozanini]

Bah, so bite me. :D

I never used these versions and have always relied on v.1.2.3 my whole life (IIRC semver recommend this approach). If semver is that permissive, I don't see why not.

[ricardozanini]

@cdavernas not sure if they are compatible, at least from the regexp pov: https://regex101.com/r/vkijKf/1/

Test the examples I had. From an SDK perspective, I would apply this regexp, which will fail if someone out there decides to use one of them.

[cdavernas]

@ricardozanini yeah, alpha alone is indeed invalid, but it's a valid suffix: 1.0.0-alpha for example.

And yeah, I feel you man, I likewise used single then four digits versions a lot until I ran into semver.

[ricardozanini]

Kubernetes CRDs use v1alpha1, v2beta1, and v1; this is not valid whatsoever. I'm just trying to play the devil's advocate here, and try to see if we can do more detriment than good when imposing such a thing.