Tomorrow's nightly will output the new version format when running roc version:
Roc compiler version nightly-2026-August-1-123abcd
I suspect this will not break things for many people but I bet some people rely on the specific format.
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:
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.
If enough people want to change this, I will, because Github understandably messes up the sorting too.
Reverse dates we all do it the same, YYYY-MM-DD
I think the Americans will forgive you for using YYYY-MM-DD <3
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
I think it's the ISO standard
As an American, I will forgive any format that is more sensible than MM-DD-YYYY
yeah as an American if I see YYYY- first, I expect month next
since that ordering only ever comes up with the year-month-day standard
I would also prefer YYYY-MM-DD in the version as well as in the title of the release
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.
For tagged releases a version- prefix would also sort the same way (assuming 0 padding) but that only works for tagged ones.
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
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.
@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.
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).
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?
Anton said:
Instead of a version string with
stablein 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.
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)
(and there won't be a
betaor 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
The next nighty will have the version format nightly-YYYY-MM-DD-short_sha
Last updated: Aug 12 2026 at 12:35 UTC