I don't have any real preference on the version numbering. I personally dislike semver and prefer time based versioning but that's a pretty minion opinion.

I'm a massive +1 to keeping each spec versioned separately, that's why the CRDs all have their own groups.

@grampelberg thanks. what do u mean by time based versioning?

Couple examples:

• CoreOS - 2191.0.0 or number of days since the first release.
• Linkerd - edge-19.9.5 or 5th release of september in 2019.

My primary reasoning is that if you use something semver like, people make assumptions about the guarantees and those assumptions are usually wrong. Picking a completely ridiculous date forces them to look at the changelog. I like using dates for this because it helps with debugging "oh, you're on that release from a year ago".

In agreement with @grampelberg, I find that there's often a need for semver+. e.g. major.minor.patch+candidate/something else.

We discussed a path forward for versioning of this spec, and using submodules in the go sdk to keep track of those version dependencies. We punted on the exact versioning scheme for the go SDK releases and left it up to the person that does it to pick something reasonable. In that context, I would make a stronger case for semver or something that looks like semver, just to play as nice as possible with go tooling.