-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shorter release cycles #4504
Comments
I think shorter release cycles grow in value the more stable the language is. Zig users are already living on the edge, and if they are wanting to get the latest changes, master is available as a nightly download from Ziglang.org. Keeping the release cadence slow while the language undergoes many breaking changes achieves two social wins: There is a large development win with a slow release cadence for immature languages: There is time to pause and ponder and experiment with multiple implementation paths without the pressure of meeting a deadline. |
It's not time yet. @JesseRMeyer is correct that this has to do with stability. You'll notice we also don't have any bug fix releases yet. The "LLVM-locked" release cycle will remain status quo at least until the language is stabilized and specified (#75). You'll have to trust me on this, I have put a lot of thought into how the release cycle works and will work in the future. I'm optimizing for getting to 1.0.0 as soon as possible, as well as attracting a steady, but not explosive, flow of new community members. |
Maybe we should indicate that the nightly build is "almost as stable" as the release cycle? The versioned releases give a lot of warm fuzzy feelings that's largely untrue after about a month in. |
Thanks for helping me understand your thoughts on the release cycle. I am happy that its well thought out. |
Can we have a shorter release cycle for zig and make smaller but more frequent releases?
Its been 4+ months since the last release and a young language like Zig can benefit more from faster iterative updates.
Something to the tune of 1 release every month should be good.
so instead of doing a
0.5 -> 0.6 over 6 months, we could do
0.50 -> 0.51 -> 0.5x ... -> 0.60
The text was updated successfully, but these errors were encountered: