Proposal: add zig_version field to build.zig.zon

[marler8997]

This issue proposes the field zig_version be added to build.zig.zon.

zig_version would specify the latest zig version that the project has been tested to work on. If a project goes to the effort of supporting multiple zig versions, it can indicate backward compatibility with the existing minimum_zig_version field. This provides a mechanism for projects to report compatibility with multiple versions of zig, which is useful for both users and future tooling.

In practice, I expect most projects to only use zig_version. minimum_zig_version would be most useful for projects that have many other projects depending on them, where the effort to support multiple versions might be justified. For this reason I additionally propose that zig_version be a REQUIRED field for all projects moving forward and minimum_zig_version be kept as OPTIONAL.

P.S. the zig_version would not exclude compatibility with future zig versions, but, would serve as an indicator that you're in "uncharted waters" for that package

• reference: original minimum_zig_version proposal

[nektro]

while this could provide some great dx in the meantime i think its worth pointing out that it will not be necessary post-1.0 and minimum_zig_version would go back to the one providing much more value.

are you envisioning a warning printed during zig build ?

are you envisioning it treating master vs tagged releases any different?

[marler8997]

Once the language hits 1.0, Zig may still bump its version to reflect changes beyond just the language itself, like updates to the stdlib or tooling. If not, then we might eventually want a new field like toolchain_version or minimum_toolchain_version?

Regarding warnings: I can imagine cases where this version info could help Zig guide users when something isn't working as expected, but I'd need to explore the implementation to say for sure. That said, the biggest DX improvements I had in mind come from making this new field required, which are:

• No more wasting time figuring out which Zig version a project requires. I curse every minute of my life wasted doing this.
• Forgetting to update the version when you make breaking changes with the old version is no longer possible.
• Tooling like ZLS, zig fmt, editors, etc., could derive which version of zig to use for specific files/projects.

An alternative solution to get the same benefits would be to make minimum_zig_version required, but that forces projects supporting multiple versions to advertise the oldest one when they’d probably rather highlight the latest. I find it's always useful to specify the latest known working version, but only sometimes useful to specify an older compatibility version.

I haven't been able to come up with a use case that shows why we'd need to treat dev/release versions differently, so let me know if you think of any.

[VisenDev]

if .zig_version is mean to be the maximum version the project works with and .minimum_zig_version is the minimum version the project works with, wouldn't it be more consistent to use .maximum_zig_version instead of just .zig_version?

[nektro]

i interpreted .zig_version not to be the maximum it works with, moreso the maximum its been tested with by the author. forwards compatibility is highly likely but it can be good to note the latest known-good version should that ever not be the case and .minimum_zig_version needing a bump