Skip to content
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

Closed
rishavs opened this issue Feb 19, 2020 · 4 comments
Closed

Shorter release cycles #4504

rishavs opened this issue Feb 19, 2020 · 4 comments
Labels
proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Milestone

Comments

@rishavs
Copy link

rishavs commented Feb 19, 2020

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.

  • Zig users will get fixes and new features much faster
  • more releases and their related discussions will get more mindshare from the tech crowd

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

@daurnimator daurnimator added the proposal This issue suggests modifications. If it also has the "accepted" label then it is planned. label Feb 19, 2020
@JesseRMeyer
Copy link

JesseRMeyer commented Feb 19, 2020

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:
1.) When there is a release announcement, there is much to talk about. Many tiny changes normalize with high frequency.
2.) Window shoppers will be less hesitant to join the party if they feel what they learn now will soon be invalidated by the next short term cycle. The cost is with fewer announcements comes fewer eyes, which I think is your main point. I don't know which wins out at this stage in a language's lifecycle.

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.

@andrewrk
Copy link
Member

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.

@andrewrk andrewrk added this to the 0.6.0 milestone Feb 19, 2020
@fengb
Copy link
Contributor

fengb commented Feb 19, 2020

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.

@rishavs
Copy link
Author

rishavs commented Feb 19, 2020

Thanks for helping me understand your thoughts on the release cycle. I am happy that its well thought out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Projects
None yet
Development

No branches or pull requests

5 participants