What to put in the version field of my build.zig.zon?

Help
1

The docs for build.zig.zon and I think most comments by the zig team on the package manager state that I should put the semantic version of my package into the .version field of my build.zig.zon file.

Is this the recommended work flow to accomplish this?

  1. Have software ready to release committed to github.
  2. Change .version field in build.zig.zon to first released version of 0.1.0.
  3. Commit change of version field.
  4. Tag that commit with v0.1.0
  5. Change .version field in build.zig.zon to 0.1.0-dev
  6. Commit change to version field
  7. Push to github
  8. In github, select commit with tag v0.1.0 as a release
  9. Profit?

The main question is, does this mean my build.zig.zon should almost always contain a X.X.X-dev version unless I am making a commit that tags a release?

2 Likes
2

That seems like more work than is really warranted. The .version string isn’t used by anything at the moment. The workflow you describe is, broadly speaking, how I make releases however.

I’d say that if you’re going for coherency, making sure that the .version string matches any tags you create, and accordingly any release versions, is enough (and that generally package maintainers should ensure this).

Once I have a published release version of a library, I generally make feature branches for anything which deserves a minor version bump, and commit bugfixes directly to the trunk branch. Ideally as one commit, but in any case only pushing to origin when I have a tagged commit with the Zon file and README updated to point to the next release, which I then promptly create.

Just remember that by SemVer §9 a semver string with a hyphen ranks below the same string with no hyphen, so if you want to use a -dev suffix for any intermediate commits, you’ll want to immediately bump from vA.B.C to vA.B.C+1, or B or A if working on a minor or major version.

Basically I figure that anyone looking for “official” code is looking for tags, and probably released versions, so I make the effort to ensure that those are coherent. I only use suffixes on tags, and (therefore) releases, if I need a specifically pre-release version published, for whatever reasons.

But if it makes more sense to you to ensure that every commit has a semver-correct .version string, don’t let me stop you. There aren’t any tooling consequences for not doing that now, I doubt there will be, but it might help you in terms of using your commit history for example.

2 Likes