yeah maybe the time has come to start talking about an 0.1.0 release then!
one of the things I'd really like to do before we ship 0.1.0 is to add a roc cli command that lets you switch versions
Maybe start a thread about what you'd want finished (even if rudimentarily) before popping the cork on 0.1.0? Both for the language, and all the general tooling and tutorials and whatnot
something like roc switch 0.2.0 which downloads 0.2.0 into a cache (if you don't already have it) and then replaces itself with that, such that after running roc switch 0.2.0 and then roc --version it prints 0.2.0
I think the only other thing is versioning builtin docs, but maybe there's something else I'm not thinking of :thinking:
After all, with the new website launch it feels about the right time. And yeah, I think a thread would be good just so others can pop in their ideas
I guess something worth discussing is whether root module headers should include a roc version
I'm on mobile and can't move the messages, but yeah I agree that a separate thread makes sense :big_smile:
Give it a little while to stew, maybe do a secondary social media push just so more people might find this little zulip space and contribute
Figure out if there's anything obvious that's hiding in plain site that only fresh eyes would see
maybe do a secondary social media push
I'm busy enough as it is :sweat_smile:
something to consider is that numbered releases will slow down development somewhat. Every release takes project management and time to implement, we'll need to start maintaining a changelog, etc.
Even if we wanna do it soon, it doesn't need to be right right now
I don't know how to slice these messages off into another thread, can someone do that?
so we shouldn't take it as a given that now is the right time to start taking on those costs. Maybe after discussing more, we determine it's best to stay unversioned for now.
15 messages were moved here from #ideas > platform api versioning by Anton.
Sure. Maybe now is right, maybe not, but now is definitely the right time to be asking these questions so we can start trending towards an endpoint. It's good to have a sense of how you're gonna end something and how you reach there
For me the breaking platform changes and this excerpt from an issue are the main reasons I'd want a numbered release:
Spend half an hour reading through examples, docs and stuffing around compiling broken stuff to try to figure out the accepted method of running two print statements.
my default thinking has been "it'll slow us down, so let's put it off as long as point until not having a numbered release is a sufficient pain point to justify paying the cost of slower development" :big_smile:
Quick q - how much of a pain would it be to get things running natively on windows for a 0.1 release? I don't know enough to know why it would be easy or hard, but it's always been baffling to me how much more work it is to get basic language stuff working on the most popular desktop OS in existence.
Conceptually that feels like a nice point to do that, but I have 0 understanding of what that would actually take.
From the little I know, windows is apparently... a bit of a pain.
roc.exe already run on Windows, but it has the most bugs and some slowness issues
Its pretty much just 128bit stuff that is failing with llvm. Nothing major, but woth the way things are set up between zig and roc its a bit fragile so there is a tradeoff between fixing that first or carving out more exceptions for windows.
Also, I'm assuming Inspect derive lands soon and all those bugs disappear, cause that is definitely not working atm on windows
Oh I was still running on the impression I needed to do janktacular shit with linux subsystem.
When I say nothing major, I think almost all the parts are there and working. Just there is some calls to llvm that need to be updated to handle 128bit stuff which changed with zig 11 to be passwd by reference on windows.
Also there is a long tail of smaller bugs with other tests and toolchains that need to be sorted through for windows.
I don't think we should try to wait with the numbered release until windows is "done". I think the seemingly last 3% of windows work can take a long time.
Anton said:
I don't think we should try to wait with the numbered release until windows is "done". I think the seemingly last 3% of windows work can take a long time.
I trust you guys to know best on this one. It does feel like some sort of deadline for "finishing" the windows stuff would be appropriate, however. Certainly it would make it easier for more people to try it out on a whim, reduce the friction, all those startup buzzphrases
I don't think setting arbitrary deadlines for ourselves is a good idea in general at this stage in the language :big_smile:
True true, and perhaps deadline was the wrong term. I guess some sort of criteria by which to identify when such a thing ought to be done is closer to what I was trying to say.
Anton said:
For me the breaking platform changes and this excerpt from an issue are the main reasons I'd want a numbered release:
Spend half an hour reading through examples, docs and stuffing around compiling broken stuff to try to figure out the accepted method of running two print statements.
I don't think that was about breaking platform changes. It was about not knowing they need to use Task.await. an easy fix for that is switch hello world to print with 2 tasks
I'll ask to make sure
@Anton that issue was why I rewrote the Task example. So people would have a really clear example for how to builds things. The current Task example is just a wall of comments and really doesnt help that much unless you already know the semantics
I'll ask to make sure
This was indded not due to out of date or incompatible roc code.
Last updated: Jun 16 2026 at 16:19 UTC