A lot of new zig users go to Download ⚡ Zig Programming Language page to start experimenting and see master version been offered first.
So this is also something to change
2 Likes
I think it is good to keep it sorted by date, meaning that master branch should stay at the top.
It I think it would be more confusing if its not sorted but maybe adding unstable in bold font near master will help?
1 Like
I apologize - that came out harsher than I intended.
2 Likes
From the perspective of someone who is deeply involved with maintaining the project, I can see that making sense. However, I strongly, strongly encourage you to take a step back and consider the “I heard Zig is pretty good, I should give it a try.” type of user’s perspective.
They will find the official page, go to the download section, and click the version at the top. The modern web has agreed on the design layout shorthand that we use prominence to guide users to the intended links.
Even a dev familiar with Git might make the same assumption. They literally won’t even see links for 0.13.0 until they scroll down a bit.
Let’s look at how the gold standard of onboarding and broad adoption does it:
The big bright button on the website is for the equivalent of the Zig’s current tagged version. You’ll notice Python calls 3.13.1 the “latest” version, even though it isn’t. Below that, in a significantly smaller font, is the link for devs who want to use a pre-release version.
There is effectively no chance someone who wants to use Python will wind up with a version of Python that is ahead of current documentation or existing libraries, or might break in a week.
This stuff matters. It isn’t a good use of time for someone like you, or anyone else who has the technical ability to contribute to the Zig codebase to work on this type of thing, but that doesn’t mean it isn’t worth improving.
- Jas
6 Likes
Apology accepted, no hard feelings. 
- Jas
3 Likes
Adding foldable sections or table of content would also help.
Pros:
- new user can see 0.13.0 and master at the same time without scrolling and discrover what 0.13.0 is that they should use.
Cons:
- advanced users would need to do 1 more click to open foldable
2 Likes
i think either of those could work, with the adittion of unstable next to master to make it clearer that its not stable
yea but for this we would need to add logic to check users OS. In status quo its just static site
As a new zig user, there are a few things I love seeing when attempting to use another’s library or module:
- It’s developed and built with 0.13.0 (or latest stable)
zig build testruns without fail- It doesn’t have dependencies
Things that I don’t like:
- Making your library depend on a non-stable version of zig
- New features require compiler update that isn’t a stable zig
I’m writing code and want my friends to use it. I want to tell them - brew install zig, git clone my repo, zig build run. If any of my dependencies break that flow, I find it irksome, and using a non-stable (even mach-nominated) version of zig breaks that flow.
The stable release is definitely the one I recommend when asked the question which zig to get. It causes the least surprise and least friction.
Cheers. 
5 Likes
FWIW I would like to see a feature in the package manager where I can force-override a dependency in the top-level build.zig.zon with an alternative version (maybe my own fork), and this then gets picked up in the entire dependency tree.
There is also the problem that different higher level dependencies may depend on different versions of the same lower level dependency. I’d like enough control over the dependency resolution to force those different dependencies somewhere down in the dependency tree to one version (while being fully aware of the downsides).
4 Likes
This is what I tried at first as library author, but interestingly most users seem to go with the latest bleeding edge version so it was actually less hassle for everyone to keep the main branch uptodate with Zig nightly (depending on how far nightly was moving away from stable of course, the same version can support both nightly and the last stable for a surprisingly long time, for instance sokol-zig is still both 0.13.0 and 0.14.0-dev compatible - with some 0.13.0 vs 0.14.0 compatibility hacks that will be removed once 0.14.0 is out).
2 Likes
Planned feature 
One thing that library authors can do is support a wider range of versions by doing conditional compilation on the zig version. I think I saw you mention already doing that practice.
edit: of course after I wrote that I scroll down and see you mention it in the very next post 
8 Likes
@AndrewKraevskii That kinda thing is just implementation details.
@vulpesx How about this kind of language?
1 Like
As an example, How would I go about finding the version of GitHub - floooh/sokol-zig-imgui-sample: Sample to use sokol-zig bindings with Dear ImGui that works with zig 0.13.0 ? According to the note, it is no longer compatible with 0.13.0 .
Skim for when the breaking change was pushed.
Again… this is why I’m a fan of big buttons at the top of pages.
it’s missing the minimum_zig_version field which is intended to provide this information.
1 Like
Library authors should be encouraged to include links to tagged version compatible releases on their repo’s README until we have a real package manger cli that does the figuring out for users. I’d propose putting that in the documentation.
i think most people shouldnt have any issues with that