Nominated Zig versions

Zig projects in the wild often use either stable Zig or nightly Zig.

• Stable Zig releases often occur just once or twice a year.
• Nightly Zig, as the name implies, gets released every night from the ‘main’ branch of Zig.

For projects like Mach wishing to keep up with modern Zig developments and improvements, stable Zig is simply too infrequent and outdated (waiting 6-12 months to get an awesome new feature like incremental compilation, or a critical linker fix, is not ideal.)

But nightly Zig is far too frequent: if every project is targetting a new Zig version every day, then libraries tend to not be compatible with one another in practice.

Nominated Zig is a sweet-spot between stable and nightly Zig: we nominate a new nightly Zig version every 6 weeks and target that.

This gives everyone 6 weeks to update their projects to the same Zig version, and everyone can move ‘in unison’ keeping their projects compatible with one another - rather than targetting a wide array of nightly Zig versions.

Schedule

On these days, the current nightly Zig version is nominated.

No special testing is performed beyond what Zig nightly already performs in e.g. its continuous integration testing. Sometimes a version may not be stable enough for a project using Zig, in which case you can e.g. hold back one version until the next one is nominated just 6 weeks later.

Nomination occurs on Thursdays, to give people (who are often maintaining Zig projects over their weekends) the ability to do so promptly on their weekend rather than during the week.

Where to get old versions

ziglang.org periodically purges old nightly Zig versions. As a result, recent nominated versions may be available there but older ones may not be. https://pkg.hexops.org is a Zig download mirror which hosts even older nominated Zig versions, and many popular tools in the community integrate with it directly.

Machine-readable version history

https://pkg.hexops.org/zig/index.json provides a machine-readable version history. It is a strict superset of https://ziglang.org/download/index.json - but with Mach versions added. A few types of Mach versions are added:

• mach-latest -> always the latest nominated Zig version.
• 2024.1.0-mach -> a nominated Zig version in YYYY.MM.DD-mach format (leading zeros omitted)
• 0.3.0-mach -> an alias for the nominated Zig version that was used at the time of Mach v0.3 release.

What if we had just used stable zig in the past?

Periodically, the question comes up: “why not just use stable Zig versions?” The best way to answer this, and our own gauge for answering this, is to look at how this would’ve affected us in the past.

• Between Zig 0.15 and 0.16:
  • Early access to Zig’s SPIR-V compiler backend, and ability of some Mach contributors to contribute to the SPIR-V backend, helped influence our future decisions for shading language.
• Between Zig 0.14 and 0.15:
  • The usingnamespace removal, http client, and writergate were beneficial for us.
• Between Zig 0.13 and 0.14:
  • We were able to identify a linker regression which prevented Mach from building/linking at all on macOS. This regression likely only affected Mach, as most projects do not use Zig ObjC bindings. If we hadn’t been able to identify this regression and give feedback to the Zig core team (who thankfully was able to fix it quickly!) then we may not have been able to upgrade to Zig 0.14 while keeping macOS support.
• Between Zig 0.12 and 0.13 (1.5 months):
  • We were able to identify a linker regression which prevented using prebuilt binaries on macOS, exactly one day after the 0.12 release. Again, this regression likely primarily affected Mach - so if we had been using stable Zig, we’d need to hope it got fixed in 0.13 which was a short development cycle - or wait ~10 months for 0.14 / regress our macOS support.
• Between Zig 0.11 and 0.12 (8.5 months)
  • We were able to provide early feedback on the package manager and get various bugs/issues with it fixed for our use cases, being probably the earliest / most serious adopter of it. If we had not done this, we would’ve had no choice but to maintain our pre-package-manager dependency management system until Zig 0.13 was released ~10 months later.
• Between Zig 0.10 and 0.11 (9 months)
  • Early package manager feedback.

Installing Zig versions

We encourage using anyzig to manage Zig versions on your system. Remove any existing zig installation on your system first, then download the ‘zig’ binary from anyzig and put it on your system PATH.

With anyzig, you can easily switch between Zig versions in your projects by writing the Zig version in your build.zig.zon file:

.minimum_zig_version = "0.16.0-dev.3142+5ccfeb926",

Or for Mach nominated versions:

.mach_zig_version = "2024.11.0-mach"

Then when you run zig commands in your project, anyzig will read build.zig.zon and automatically use the correct Zig version.

• Learn more about anyzig: https://github.com/marler8997/anyzig
• Install it: https://marler8997.github.io/anyzig/

Nominated Zig history

Install Zig 2026.4.10-mach

.mach_zig_version = "2026.4.10-mach"

Install Zig 2024.11.0-mach

.mach_zig_version = "2024.11.0-mach"

Install Zig 2024.10.0-mach

.mach_zig_version = "2024.10.0-mach"

Install Zig 2024.5.0-mach

.mach_zig_version = "2024.5.0-mach"

Install Zig 2024.3.0-mach

.mach_zig_version = "2024.3.0-mach"

Install Zig 2024.1.0-mach

.mach_zig_version = "2024.1.0-mach"