Reading the entire spec, I think what we really want is status quo, except bump the release number directly after a release. https://semver.org/#spec-item-9

So here's the plan:

• change nothing until 0.3.0 is released, then
• change the version in git to 0.4.0 so that source builds look like 0.4.0-fc87f6e

Pre-release identifiers (stuff that goes after a dash) are used for version ordering. Using commit hash in that section doesn't make sense. It would be better to do something like 0.4.0-alpha+<commithash>. Or if you want to have ordering among pre-release versions, you could add something like commit timestamp or depth to latest tag.

You're right. My mistake.

I thought about this some more, and builds from source that are not official release tags are not intended to follow semver. They cannot be meaningfully semver-compared with actual releases. Semver is for zig releases, not for all source builds.

FWIW, the reason I lgtm'd this is that while you're right they can't be meaningfully compared, people will try to parse the version number anyway. At least now they can do it using standard tooling.

Alright that's fair. I hope it doesn't break the appveyor script, but let's deal with that if it happens.

Thanks for accepting the PR. Before I saw the PR got merged, I wrote this out as a final appeal. I guess it's still worth sharing.

My thoughts on the version string through the lens of zen:

Edge cases matter.

Building from untagged source is an edge case.

Only one obvious way to do things.

Reduce the amount one must remember.

SemVer compliance, even for untagged source builds, means that users can take any build of Zig and pass the version string to a SemVer-aware tool. They won't need to know about the possibility of a second, non-SemVer format.

Communicate intent precisely.

SemVer facilitates precision, even when the intent is "these builds cannot be meaningfully compared". Using the same pre-release identifier (e.g. -dev) for all untagged source builds will have that effect. (If that's desirable, I'm happy to do it in another PR.)

Finally, if Zig is going to mandate SemVer for its package ecosystem (my current understanding of the plan), consistent use of SemVer is a form of dog-fooding and sets a good example.