Hi,
I’m in favour that the Zig team releases much quicker bug-fix-releases.
I.e., after the release of version 0.14.0, there were quite some issues collected and adressed. But even after 2.5 months, there is no bug-fix-release with fixes which have already been adressed.
Why not release the first bug-fix release after 4 weeks? I think a 4-6 week-cycle for bug fixes would make sense in general. Rust has also a cycle of 6 weeks. But in contrast to Zig, it also contains features, which might not comply to the Zig philosophy.
Big fixes are integrated into the master branch. the idea being that if you want some fix you use some nightly build that works. Yes, it’s not as nice as a tagged patch release, but you need to consider the limited time and resources available and how they are used. Zig is “pre-release” software in a way, and using it means “participating in it’s development”. I see this as part of that.
I would have liked to have gotten 0.14.1 out earlier too. The team has been busy with other things lately. Such is the nature of a small team and pre-stable release. Is this causing a problem for your project in some specific way?
No, it’s not causing problems. I’m just an observer, but a developer for a living and there are regularly customers which need a hot-fix very fast and we even do this in a small team.
So, it might not block me, but actual users of Zig.
Just an idea.
I think most active users of Zig are on the nightly versions anyway, at least that was the impression I got with sokol-zig. The actual Zig releases are sort-of publicly visible milestones, but in reality they don’t matter much for users.
I would recommend managing your Zig install through a tool like zvm or zigup, that way it’s trivial to update to the latest nightly, switch back to a stable version or stick to a specific nightly version if there’s a ‘bad version’ for a couple of days.
(also one advantage of sticking close to the nightly build is that upgrading to the next Zig release is much less effort since instead of one massive fix effort the same work is spread over many smaller incremental fixes).
I don’t really see how a quicker release cycle is possible without better management of breaking changes. The dev team would basically need to maintain two separate dev branches in git, a stable one with only bug fixes and another one incorporating improvements that can break stuff. I don’t think the human resource is there to make this happen.
Speaking only for myself, I’ve decided not to support Zig master in my libraries until September at the earliest. I don’t have the bandwidth to keep feature parity between two branches on everything, and the nice thing about point releases is that you can target them for awhile.
If it comes up I might be willing to accept a patch on an upstream branch, but I can’t promise to keep it in sync with any changes.
That won’t be tenable forever of course. But it will serve for a while.
Well, as long there’s robust checks in place to ensure compatibility. Developers working downstream on tooling and libraries can’t be expected to keep up with such a fast release cadence. New point releases would have to work with what’s already out there. Bug fixes would have to be implemented in such a way that they wouldn’t break existing workarounds.
I’m kind of really new in zig since I started learning and really using it 1 week ago (language is really good for replacing C and C++) but I could see on my 0.14.0 compiler some issues when cross compiling to my old arm64 android phone where the default system paging size was unable to be retrieved which would lead to assert error in debug.
I try like 2h to understand why 0 was retuned but in the end I just decided to try the master version of the compiler and now the default system page size is 4096 and I have no longer those crashes on android.
I’m still confused why 0.14.0 did and did not found anything on github issue about that but for now master is fine for my android builds.
But I can understand the appeal of having something declared like « 0.14.1 » if I want someone else to build my code and not to fall into the same strange bug (bug that may be like an unique bug only visible with my phone)