Stream: announcements

Topic: Breaking change: `roc version` output


view this post on Zulip Anton (Jul 31 2026 at 18:17):

Tomorrow's nightly will output the new version format when running roc version:

Roc compiler version nightly-2026-August-1-123abcd

view this post on Zulip Anton (Jul 31 2026 at 18:18):

I suspect this will not break things for many people but I bet some people rely on the specific format.

view this post on Zulip Fábio Beirão (Aug 03 2026 at 06:44):

Sorry for the pet peeve, and sorry if I missed the context/discussion, but I don't (immediately) see the benefit of having "August" instead of 08 . Usually for sorting, this is a nightmare. The year is already correctly the first part 👍🏻 Then month (08), then day (01). Again: pet peeve, so apologies if I'm the only one with this trauma :sweat_smile:

view this post on Zulip Anton (Aug 03 2026 at 12:24):

I did it that way because Americans use a different date format than Europeans and if I see the date 4-12-2025 in an international context I never know if that is the 4th of December or the 12th of April.

view this post on Zulip Anton (Aug 03 2026 at 12:27):

If enough people want to change this, I will, because Github understandably messes up the sorting too.

view this post on Zulip Luke Boswell (Aug 03 2026 at 12:27):

Reverse dates we all do it the same, YYYY-MM-DD

view this post on Zulip Niclas Ahden (Aug 03 2026 at 12:28):

I think the Americans will forgive you for using YYYY-MM-DD <3

view this post on Zulip Anton (Aug 03 2026 at 12:29):

Luke Boswell said:

Reverse dates we all do it the same, YYYY-MM-DD

We never do reverse dates in Belgium, but it is a logical order though

view this post on Zulip Luke Boswell (Aug 03 2026 at 12:30):

I think it's the ISO standard

view this post on Zulip Bryce Miller (Aug 03 2026 at 12:33):

As an American, I will forgive any format that is more sensible than MM-DD-YYYY

view this post on Zulip Richard Feldman (Aug 03 2026 at 12:49):

yeah as an American if I see YYYY- first, I expect month next

view this post on Zulip Richard Feldman (Aug 03 2026 at 12:49):

since that ordering only ever comes up with the year-month-day standard

view this post on Zulip removewingman (Aug 03 2026 at 12:50):

I would also prefer YYYY-MM-DD in the version as well as in the title of the release

view this post on Zulip Arya Elfren (Aug 03 2026 at 12:58):

If we're already considering sorting I'd advocate for date completely first, as in YYYY-MM-DD-TYPE-rev. In a sorted list I'd want to have all of the most recent versions together, no matter if nightly or not. I've also had it before (with a different project) where I had to scroll past 10 years of nightly releases to get to the stable from yesterday.

view this post on Zulip Arya Elfren (Aug 03 2026 at 13:00):

For tagged releases a version- prefix would also sort the same way (assuming 0 padding) but that only works for tagged ones.

view this post on Zulip removewingman (Aug 03 2026 at 13:03):

Arya Elfren said:

If we're already considering sorting I'd advocate for date completely first, as in YYYY-MM-DD-TYPE-rev. In a sorted list I'd want to have all of the most recent versions together, no matter if nightly or not. I've also had it before (with a different project) where I had to scroll past 10 years of nightly releases to get to the stable from yesterday.

Is this needed? As far as I understand, the release types are already separated by repositories:
Only nightly: https://github.com/roc-lang/nightlies
Actual stable releases: https://github.com/roc-lang/roc

view this post on Zulip Arya Elfren (Aug 03 2026 at 13:18):

removewingman said:

Arya Elfren said:

If we're already considering sorting I'd advocate for date completely first, as in YYYY-MM-DD-TYPE-rev. In a sorted list I'd want to have all of the most recent versions together, no matter if nightly or not. I've also had it before (with a different project) where I had to scroll past 10 years of nightly releases to get to the stable from yesterday.

Is this needed? As far as I understand, the release types are already separated by repositories:
Only nightly: https://github.com/roc-lang/nightlies
Actual stable releases: https://github.com/roc-lang/roc

I'm thinking about other package repositories, list on websites/mirrors, cli command output, etc. It is additional bike-shedding I admit, so definitely not needed.

view this post on Zulip removewingman (Aug 03 2026 at 13:58):

@Arya Elfren makes sense, did not thought about this. It is already in the name tho, e.g.

One could also copy what zig does, once there is 0.1.0, they prepend -dev

I do not have a opinion on this.

view this post on Zulip Arya Elfren (Aug 03 2026 at 14:23):

removewingman said:

Arya Elfren makes sense, did not thought about this. It is already in the name tho, e.g.

Yea, it's just about re-arranging the information. Basically the difference between the outputs:

$ hypothetical-roc-install list --all | sort --reverse
stable-2026-10-01-123abcd
stable-2026-09-01-123abcd
stable-2026-08-01-123abcd
... potentially many pages
nightly-2026-10-01-123abcd
nightly-2026-09-01-123abcd
nightly-2026-08-01-123abcd
... potentially many pages
$ hypothetical-roc-install list --all | sort --reverse
2026-10-01-stable-123abcd
2026-10-01-nightly-123abcd
2026-09-01-stable-123abcd
2026-09-01-nightly-123abcd
2026-08-01-stable-123abcd
2026-08-01-nightly-123abcd
... potentially many pages

Which allows you to do | head for the latest of any kind. You can also answer questions like "latest stable if there was one in the last 2 weeks if not then the latest nightly". It also means that adding a new "type" (like rust's beta) it wouldn't get buried.

Also the added benefit of aligning the dates visually (in monospace).

view this post on Zulip Anton (Aug 03 2026 at 14:55):

Instead of a version string with stable in it, I think it would just be the numbered release like 0.1.3, or are we thinking about different things?

view this post on Zulip Arya Elfren (Aug 03 2026 at 15:23):

Anton said:

Instead of a version string with stable in it, I think it would just be the numbered release like 0.1.3, or are we thinking about different things?

If it's always prefixed by nightly- and stable versions have a different format (and there won't be a beta or similar that wants a similar format) then sure. I just assumed that nightly was adding to the information provided by the string, if the format is only used for nightly releases ever then it's a constant and my point doesn't stand.

view this post on Zulip Arya Elfren (Aug 03 2026 at 15:27):

In that world I agree that this:

$ hypothetical-roc-install list --all | sort --reverse
4.1.0
2026-10-01-nightly-123abcd
2026-09-01-nightly-123abcd
2026-08-01-nightly-123abcd
1.3.9
0.1.3
0.0.1

is worse than:

$ hypothetical-roc-install list --all | sort --reverse
nightly-2026-10-01-123abcd
nightly-2026-09-01-123abcd
nightly-2026-08-01-123abcd
4.1.0
1.3.9
0.1.3
0.0.1

(though you'd have all the nightlies (many more than stables) before the first stable)

view this post on Zulip Anton (Aug 03 2026 at 15:29):

(and there won't be a beta or similar that wants a similar format)

I like the zig style for once we have numbered releases: 0.17.0-dev.1543+6db520a4c.tar.xz

view this post on Zulip Anton (Aug 05 2026 at 14:38):

The next nighty will have the version format nightly-YYYY-MM-DD-short_sha


Last updated: Aug 12 2026 at 12:35 UTC