Anton (Aug 24 2024 at 10:40): Anton (Aug 24 2024 at 10:40):Breaking changes are quite common in Roc and I want to prevent people from hitting strange errors when trying to run code that is not updated to the latest nightly. So, I'd like to have versioned Roc releases and include the version in the header of app, package and platform files.
Anton (Aug 24 2024 at 10:40):This would also prevent us from needing to update every important platform and package as quickly as possible when a breaking change happens.
Anton (Aug 24 2024 at 10:40):If we don't feel ready to call it 0.1 yet, we could call it beta-0.1 or something like that.
Anton (Aug 24 2024 at 10:40):Some previous drawbacks from earlier discussions:
Anton (Aug 24 2024 at 10:41):The effort seems acceptable to me; we can just polish up the github auto-generated release notes a bit and show some examples of how to upgrade for breaking changes or new syntax. The release notes don't need to be top tier for now.
Anton (Aug 24 2024 at 10:41): Anton (Aug 24 2024 at 10:41):We can add this before doing versioned releases, it does not seem like a lot of work.
Anton (Aug 24 2024 at 10:41):I believe that being able to take any Roc code that used to work and run it easily would be awesome :)
Hannes (Aug 24 2024 at 14:17):Could use all zeros to show just how unready the compiler is? E.g. 0.0.0-alpha-1
Brendan Hansknecht (Aug 24 2024 at 16:32):Anton said:
This would also prevent us from needing to update every important platform and package as quickly as possible when a breaking change happens.
I don't think it would really. Once a breaking change lands. People will be living at source and at nightly. For all the core roc packages we will still want the updated asap.
I think this only changes once we have a more committed release cadence and planning that really pushes people off of source and nightly.
I don't think having that slower cycle is a good idea today cause often times fixes to bugs build up quick and that is more important to user perception today than release planning.
Brendan Hansknecht (Aug 24 2024 at 16:32):I personally think that instead of releases, it would be better to simply codify having two versions of the nightly. One version that is guaranteed to work with the core roc packages their current main and one that is truly the laster roc main.
We would then simply disable promotion when breaking changes come in.
Anton (Aug 24 2024 at 17:03):I don't think it would really. Once a breaking change lands. People will be living at source and at nightly. For all the core roc packages we will still want the updated asap.
Let's leave that aside for now, this was the important part: "I want to prevent people from hitting strange errors when trying to run code that is not updated to the latest nightly.". Like it can take significant effort to get roc code to run if it was written three breaking changes ago.
Fixing that by including versions in the Roc file would not require an involved release cycle with regular cadence right?
Anton (Aug 24 2024 at 17:06):If the version was included in the file, people could work their way through our release note examples of how to update from e.g. alpha-0.2 to alpha-0.3, all the way up to the release they desire.
Brendan Hansknecht (Aug 24 2024 at 17:06)::thinking:. Yeah, that definitely feels like this would help a ton. So all platforms and packages specify a roc version. Roc will give a warning if trying to compile something with an old version
Brendan Hansknecht (Aug 24 2024 at 17:07):That said, it should still attempt cause the version bump may only be a platform breaking change so a package on an old version may just run
Brendan Hansknecht (Aug 24 2024 at 17:10):I do have questions around how we batch versions and when we decide to increment the version number. Like technically instead of a version, we could just put nightly-{date} as the version string. But that feels like it might be too brittle/granular. On the other end though, a month old version of roc could be super stale depending on the month. So having a monthly released version might be really inconvenient at times.
Anton (Aug 24 2024 at 17:24):a month old version of roc could be super stale depending on the month. So having a monthly released version might be really inconvenient at times.
I'm thinking we could do a minor version release every time breaking changes happen and perhaps a patch version release for every couple of bugfixes.
Brendan Hansknecht (Aug 25 2024 at 06:12):Related to this, can we make roc built from source or as a nightly print the date and git hash as the version. The for these relaese of course print the real version number. Though a date and git hash might be useful as well.
Brendan Hansknecht (Aug 25 2024 at 06:12):Current built-from-source is not helpful for debugging. Though I think the nightlies should print a proper date???
Anton (Aug 26 2024 at 08:50):Yes, nightlies print a hash and date:
$ roc version
roc nightly pre-release, built from commit faeea52 on Fri Aug 23 09:02:06 UTC 2024
For those without git changes we can do:
built from commit faeea52 on Fri Aug 23 09:02:06 UTC 2024
And with changes, something like this?
built from commit faeea52 with additional changes on Fri Aug 23 09:02:06 UTC 2024
I'd prefer for identical builds built at different times to be exact matches, can I leave out the date for a local build from source?
Sam Mohr (Aug 26 2024 at 18:31):That's a good goal to have for version matching. Can we just put the timestamp the commit was made at? That would be consistent
Brendan Hansknecht (Aug 26 2024 at 19:06):Yeah using commit time for the date sounds like a good idea in general.
Anton (Aug 27 2024 at 08:36): Brendan Hansknecht (Aug 27 2024 at 17:09):Woah....issue numbers are in the 7000s now.
Anton (Aug 27 2024 at 17:16):That also includes PRs, but still, pretty large... :)
Hannes (Sep 01 2024 at 07:20):I've opened a nearly finished PR to add the commit information to the roc --version output, just need some help with it: https://github.com/roc-lang/roc/pull/7046
Last updated: Jun 16 2026 at 16:19 UTC