Open mochalins opened 2 hours ago
I agree, Zig is a rapidly developed language to reach the first stable version, so Zig users should always use the latest "beta" version of Zig, and we as well. So, yeah, I suggest we drop old Beta Zig versions.
@jinzhongjia what do you think?
Zig
0.11.0
support should be dropped frombuild.zig
, here is why:0.11.0
was released more than a year ago, with no0.11.1
or other patch update afterwards. As a fast moving pre-1.0 language, the Zig compiler itself makes breaking changes in each release; it seems unreasonable for us to support outdated Zig language targets in such an unstable and rapidly developed language, especially when0.11.0
was short-lived enough not to have any patch updates (unlike e.g.0.10.1
).0.11.0
was prior to many significant build system and package manager improvements; as such, it causes pointless increase inbuild.zig
complexity. Every single version check can be removed from our build script by dropping this one version.0.11.0
hinders taking advantage of Zig's testing. As Zig comes built-in with a convenient testing harness,webui
could benefit significantly with expanded CI-enabled unit tests of the C library functions written in Zig. However, supporting Zig 0.11.0 forces us to deal with not only changes in the Zig build system, but changes in the language itself within writing test cases. Such an effort would be nontrivial at best, and show-stopping in adding Zig unit testing at worst.0.12.0
(and as a followup,0.13.0
for the LLVM upgrade) as a "version that projects will want to pin". Prior to0.12.0
, the most common practice for projects was to follow Zig's master branch. A couple example major Zig projects: https://github.com/mitchellh/libxev, https://github.com/tigerbeetle/tigerbeetle, https://github.com/oven-sh/bun -- all of these projects only support Zig0.13.0
.TLDR: Zig
0.11.0
is more than a year old, in a rapidly developing language that makes breaking changes on each new version. Unless there is strong evidence to suggest that0.11.0
is widely used, there appears to be no benefit to investing the non-trivial extra cost of maintaining support.