Hi everyone, I built Zigspinner, a small spinner library for Zig focused on clean API, compile-time friendly presets, and cross-platform terminal output.
Given the recent release of Zig 0.16.0, I suggest indicate whether this works with that version or not (yet). Or what part can be used c.q. is tested with 0.16.
I looked at the source online and did see std.fs.File, so I suspected errors with Zig 0.16, and
when cloned, the source would not build out-of-the-box with Zig 0.16 (on the macOS M1 machine where I tried this). I am not complaining that it failed, as that is perfectly understandable, but I assume that others would want to know whether they can use it in 0.16, or not, before trying.
I guess you can look at the .minimum_zig_version = "0.15.2", in the build.zig.zon as an indicator (but not full confirmation) that it might only support 0.15.2 currently.
There are some packages that support multiple versions of Zig at the same time, for those Zig 0.16.0 might work too. Or some packages might just happen to work with newer Zig versions because they weren’t affected by the changes.
I also think it makes sense to use the version tags of ziggit.
I want to throw in a plug for @marler8997’s anyzig, which has made this upgrade (which I’ve barely started) so much more pleasant than it would otherwise have been.
Picks the Zig binary for a project based on the .minimum_zig_version string. Brilliant stuff.
Great point, and thanks for raising it.
You were right that compatibility needed to be explicit. I’ve now validated both Zig 0.15.2 and Zig 0.16.0 with build + tests, and updated the project docs so users can see support status before trying.
Thanks, this is a really good clarification.
I agree that .minimum_zig_version should be treated as a lower bound, not full confirmation. I now test against both 0.15.2 and 0.16.0, and I updated the README to reflect verified versions more clearly. Also agreed on Ziggit version tags, I’ll follow that.
That looks super useful, thanks for sharing this.
Using anyzig with .minimum_zig_version is a great workflow for reducing version friction, especially while supporting multiple Zig versions. I’ll mention this approach for others too.
Thanks for testing and for the detailed notes.
Good catch on the duplicate empty braile.zig file, that has been removed.
And yes, I agree on your std.Io.Timestamp / std.Io.Duration suggestion for a cleaner 0.16-focused pass.