I was wondering why we don’t have an official “zig@now” type branch/tag of the dev version which passes some arbitrary bar of stability/just straight up shadows mach-nominated.
0.xx.0 releases seem to be functioning as a sort of beta-LTS, which is a good thing. However it seems nobody really uses them, and there isn’t an obvious version to use if you go to official Zig resources. If you’re not using zvm or the VSCode extension I imagine keeping your ZLS working would also be a pain point.
Adopting an intermediate zig@now step between the last .0 release and nightly would be beneficial for three reasons:
People learning the language don’t have to try to figure out why the current officially tagged version isn’t the de-facto standard they see used in resources and projects, only to find out there really isn’t one.
Documentation/README’s/example projects will have a few months of assured reliability, a good balance between having no standard whatsoever and without having to lose out on new hotness happening in the dev branch.
The sooner the community at large gets in the habit of consistent documentation, standards adherence, and being able to rely on official Zig as a source of truth the better.
Now, off to code more Zig. I frakin’ adore this language.
Right on the Zig homepage [(https://ziglang.org/), it lists the official latest release, which at this writing is 0.13.0. So there shouldn’t be much confusion on that front.
There are no guarantees about stability at any finer granularity than this.
If you want faster stable releases, then donate money so that the required resouces can be applied.
I addressed the issue of the 0.xx.0 releases lagging behind perfectly usable and thus widely adopted dev versions.
I specifically said we could shadow mach-nominated, or pick an arbitrary bar of stability and for a month or two that’d be zig@now from an official source. It is not meant to be a guarantee of stability it is meant to be a version of the language that guarantees we’re all on the same unstable versions at the same times.
2. You should always suggest people contribute to a project with code, helping on Github, writing docs, or answering questions before you tell them to donate money. I have plenty of money and I assume, judging by your reply, you do as well; so we can donate to OSS, including Zig. Many folks cannot afford to do so.
You should never make people without financial means feel like can’t help OSS or they aren’t welcome in an OSS community.
I doubt I’d ever be able to find where this was said (and I might be misremembering, don’t take this as fact), but I believe the reasoning Andrew has given for not having more frequent releases in the past is that releases take time and effort (especially release notes), and that time and effort is better spent elsewhere.
This may be somewhat true for individuals, but probably not for projects (or at least ‘major’ projects):
Although I am not doing something “challenging/serious” in Zig currently (only some small exercises from time to time), but this is what I have on my machine:
Glad I’m not alone in juggling versions. If you haven’t already, you should check out zvm. It is very lightweight and does exactly enough. after you install it run zvm vmu zig mach zvm ls --all to list the versions available on the remote
and you can then just zvm i [version from list] --zls for whichever versions you need, then zvm use [version] --zls
I can appreciate that, and maybe I wasn’t articulating my idea very well. I’m not suggesting “releases” as such, but rather a -dev version with an easy to grab github branch/tag that is linked to from official Zig resources as a “preview” type build. This isn’t uncommon with languages.
The idea isn’t to have something that’ll be relied upon beyond the timeline of the next proper tagged release, but rather a way to designate an official dev version and make it trivial to get.
It wouldn’t require release notes other than “This is based on 0.xx.0-dev.(insert alphanumeric chaos here) and is intended to provide a preview of upcoming Zig features. It is not suitable for production use.”
This way you could just grab zig@preview and zls@preview and go about your business.
Also to clarify, I shouldn’t have said “nobody” uses tagged versions; you’re right to call me out on that. Rather I meant to say in my experience getting into Zig at this point in time the majority of smaller scale stuff uses a dev version rather than a tagged version. This includes learning tools like Ziglings, Exercism’s zig lessons, etc.
Having zig@preview would be nice for this part of the community, and I think the existence of mach-nominated is evidence of this. Again I honestly would be fine if zig@preview just shadowed mach-latest which would effectively be zero effort for the team. The idea is just to get an officially sanctioned preview version that you can easily pull from git.
Why aren’t “mach-nominated” style versions offered from official Zig?
Wouldn’t that be identical to more frequent releases, except with a slightly worse versioning scheme?
there isn’t an obvious version to use if you go to official Zig resources
Most recent released version, unless you want to get involved in development of the project, in which case master branch.
I see that the text under Tagged release or nightly build contradicts this so I’ll bring that up with Loris tomorrow and see what he thinks about changing it.
I think checking over all the website text would be a good task for me to do this month before 0.14.0 is cut.
If you need help rewriting copy on the website, I could help out.
That exact text you linked is kind of what kicked me off down this path, and probably why Ziglings and Exercism compile against dev branches. I looked at some zig.news tutorial posts, and going back quite far they consistently use 0.1x-dev. I would however begrudgingly say that with the pace of change in Zig, honestly it is kind of valid to say you should try to keep up with the features and leave tagged releases for production grade software. This is where zig@preview could come in.
It wouldn’t be identical to more frequent releases, as a “release” has the connotation of being something landmarked, and as you alluded to it has an expectation of being properly versioned.
The obscured versioning of zig@preview is a feature, not a bug in this use case. With no version, it has no implications of extended consistency. It is exactly what it says: a preview of what the maintainers are going to release next.
This is analogous to a C# “insiders”/preview, where MSFT wants devs to have a version that slowly updates with a set cadence to get people running a lot of lines of code on the same early version to find bugs, edge cases, etc that might otherwise go missed if people are spread out between various dev releases.
From a user perspective, it is just way more ergonomic to grab @preview than 0.14.0-dev.872+a60810b5a and would allow smaller projects and tutorials etc to keep their documentation more consistent.
Once again I’ll bring up the mach-nominated builds (I’m unaffiliated with the project jftr) as possible options for an official Zig resource to suggest. Reading their docs it seems they put in some good work to pick stable versions and make them easy to get.
If I should just shut up about this I’ll do so at this point. I appreciate the reply.
What it sounds like is that you are looking for something akin to Rust’s “Beta” release, where in you get to test what is coming out in the next release cycle.
I think that this would be very bad, particularly right now. While zig releases are “slow”[1], development on the nightly branches moves pretty fast. Furthermore the development isn’t always a linear progression. Some things are added and then removed. If I tag my software as using zig@preview branch there is no way to guarentee that it will continue to build, as that branch will move out from under me. With how fast the nightly branch moves, it is why projects have strictly declare what version of the compiler they are using, as there is not “pre-release” build. I think what Andrew is pointing out is that supporting a “pre-release” build would be just as much work as maintaining a full release, and would add extra comittment and work to determine “What we are comitting to releasing” vs what is just “experimental”. Right now, since everything in the language is still on the table, it doesn’t make sense to be making those commitments between releases
For what it’s worth, in my projects I use only the latest 0.x.x release. I only upgraded to the 0.14.0-dev version yesterday, since Andrew said that it should be fairly stable up to the release next month.
I’m not sure I agree. Python only releases once a year and I working with python, I don’t think it’s a very slow pace. ↩︎
FWIW I currently have the opposite problem that some sub-dependency of one of my projects is stuck on a ‘mach-nominated version’ for a very trivial change: Fix builds for Zig master by Spadi0 · Pull Request #205 · zigimg/zigimg · GitHub)… and since that’s in a dependency of a dependency there’s not a lot I can do to work around that problem except wait for that PR to be merged
What I do in my own projects (e.g. sokol-zig) is to “as quickly as possible” follow any breaking changes in the nightly Zig version (mostly I notice this in the Github CI). If the differences between the nightly version and the last stable version are still small, I maintain fallback code like this:
…or even this:
…if this is no longer manageable, I move the stable version support into a branch (which will be frozen at the time it was created)
In the beginning I had that the other way around (keep the bleeding edge version in a branch and the current stable version on main), but most people who use sokol-zig seem to live ‘on the edge’.
I think if you want more frequent tagged releases than mach nominated versions are already the solution, I don’t see a need to copy that to make it more “official”.
I think it is fine for the community to pick some version and stick to that.
Personally since 0.13 I stick to the latest release unless I need a newer version (in which case I use master) or another reason to use master is to prepare for the next stable release and potentially give feedback if you encounter errors with updating your code.
I think having people use different master versions because they update at different times is actually a good thing, that way different versions get some testing exposure.
But working with dev versions is more time investment and learning how to figure out stuff, I don’t think making everyone work with the same dev version is the right move, it may make things easier for the individual but I think it would make it worse for the project and dev isn’t optimized for people who want a “casual” experience using it as if it was a release.
So my personal take would be that it is fine to use master versions, but it can be more work and I don’t think there is a practical way to avoid that, that doesn’t have other downsides.
I’m just a fan of having sources of truth. Some people stick on tagged some are on nightly some are using Mach and some are using everything in between. I was hopeful we could get down to three official versions.
Two works though.
I think there are a few things that a consensus exists for:
For production, use tagged.
For fun and contributing use nightly.
My zig@preview pitch is dead.
If we want people to be on nightly or tagged, the official VSCode extension probably shouldn’t be able to install mach-nom. I assume a lot of onboarding happens through that route, and it’d nudge ppl away from the idea of intermediate duration release use. ZVM already defaults to only showing tagged releases when you list available, and that’s a sensible default.
I think there are many options because people prefer different options at different times, seems like a herding cats problem trying to get people to only use one way or another.
I think ZVM sounds like a good option for tagged releases.
I think the main problem I see is how to get a group of libraries and projects to agree on some version, for example the problem @floooh mentioned where a single dependency is on a slower updating version picking scheme.
I think this is a great point. The sooner the library ecosystem and tooling projects can rev up the better. Ecosystems create positive feedback loops of adoption.
Are the majority of breaking changes that pop up at this stage in Zig’s life the kind of syntax or builtins change thing that could be partially helped by writing a transpiler of sorts in C to help the migration of Zig projects to new versions?
I know the whole low level language thing will be used as a reason for not worrying about robust library development but in 2025 people don’t want to roll their own performance or security critical features. I swear like 70% of Rust projects use Tokio and serde.
There is a fair point that as Zig get’s more adopted and packages get more and more common, this is going to be a big sticking point. Once the language stabilizes it becomes less of a problem because new compilers should be able to compile old code, but until then it will be a thorn in adoption.
I didn’t mean to imply that everything should update as fast as possible, I think this is something that maintainers have to think about and decide.
But groups of connected projects and libraries should find something that works for them. I think not every project has a maintainer that can spent the time to follow master day by day and fix it as soon as something breaks, so I definitely see it as a thing where some libraries will run with the latest stable, some with mach nominated versions and some with master.
