Feature request: provide date-pinned nightly binaries (`nightly-YYYY-MM-DD`)

[MilesCranmer]

Would it be possible to provide a way to download Julia nightlies pinned by date, analogous to Rust's cargo nightly-YYYY-MM-DD toolchain selector?

The pr{number} channels are super useful. It would be nice if there was tagged nightlies as well. Right now, if I want "the nightly from a particular date" to reproduce a regression, I have to manually track down the right commit/build artefact. Otherwise the nightly channel is a moving target.

To motivate this, in one of my rust projects that requires features in an unreleased version, I have my toolchain file set up as follows:

[toolchain]
channel = "nightly-2025-12-19"

I think it would be nice if such a thing was possible via juliaup as well. I have found it is particularly useful for working on multiple machines.

[DilumAluthge]

Seems like a reasonable feature request to me.

One wrinkle: Technically, our nightly binaries aren't actually "nightly". That is, we don't build them once each day. Rather, we build and upload a new "nightly" for every commit to master. So if five commits are pushed to master in a single day, then that day will have five "nightlies". And on the flip side, if we go three days without any commits being pushed to master, then we won't have any "nightlies" for those days.

[MilesCranmer]

Interesting.

I guess the solution would be to mark the last one each day (UTC?) as the proper nightly. If a day goes by without a commit, then simply duplicate the last one.

[giordano]

Another wrinkle is that I believe the builds aren't kept in the s3 bucket forever but for 3 months or so.

[DilumAluthge]

Gahhh, right I forgot about that

[DilumAluthge]

Because each nightly build is pretty big. So it'd get expensive to store them forever

[MilesCranmer]

Would it be possible for us to keep them for a bit longer? Even 18 months would be plenty. 3 months is a bit short as in that time frame, a feature might not have ended up in a tagged release yet.

[giordano]

Even 18 months would be plenty.

I don't know the details, might not be exactly 3 months, but I don't think it's much more than that if longer than 3 months.

3 months is a bit short as in that time frame, a feature might not have ended up in a tagged release yet.

Note that all releases are cut from dedicated branches, so the "nightly" builds (which I presume would be builds on master) will never be "a tagged release".