Unable to download Julia 1.8.1

General Usage
1

I am unable to download Julia 1.8.1. Clicking on the link just keeps waiting.
Julia documentation is also not available as a pdf download.

2

I think you’ve caught the sites in the midst of a new version release where 1.8.1 hasn’t propagated across all of the Julia sites/infrastructure.

If 1.8.1 download isn’t working for you, you could still find the 1.8.0 release links here. Soon, 1.8.0 will be listed on the older releases page.

1 Like
3

I will wait for 1.8.1 to become available. Btw, it was released on 6th September and still not available!!!

4 
jill install 1.8.1

works fine for me (Linux, NL)

5

The following link
https://julialang-s3.julialang.org/bin/winnt/x64/1.8/julia-1.8.1-win64.exe
for windows is not working.

6

that’s not how it works, “release” tag on github is not release

7

Its working now. It could be some network issue on my side.

8

As far as I understand it was rather an issue with the Windows buildbots for this specific release, which is why the Windows binaries took an unusually long time to become available.

If a four day lag between release announcement and binaries being available is unacceptable to you, you should consider just building from source and thereby “cutting out the middleman” (i.e. the buildbots). Normally this isn’t an issue though, in all my time off using Julia (since v0.3) I think this is the first time that there is such a delay.

1 Like
9

Has 1.8.1 been announced?

2 Likes
10

there was no annoucement

11

A person claimed on 6th in a thread in Zulip that
Julia 1.8.1 released

This is probably the reason for the confusion.

12

It was indeed released on 6th September with no announcement: Download Julia

13

that date is when the release is tagged on github, i.e. the freeze time

14

A Julia release is not official until the announcement has been posted in the Announcements section on Discourse.

5 Likes
15

Well, it is listed at Download Julia, though. I took that as the sign that everything is official and pushed it out to Juliaup…

I would be kind of nice to rework the release process at some point so that it a) is completely automated, and b) that all things that users might interpret as “a new version is out” happen exactly at the same time, so the tag, download page update, Juliaup, versions.json etc. all occur at exactly the same time.

5 Likes
16

I agree that the JuliaLang.org website update and the Discourse announcement should happen at the same time.

However, some of the other tasks cannot happen at the same time.

For example, Buildkite cannot start building the binaries until the Git tag is created. Once the Git tag is created, Buildkite starts building the binaries; it takes multiple hours for Buildkite to build, test, codesign, and upload the binaries. The versions.json file cannot be updated until the binaries have been uploaded. Once the binaries have been uploaded, the versions.json file can be updated; it takes over an hour to update the versions.json file.

So, the release process looks something like this:

  1. A release manager creates the Git tag.
  2. Buildkite builds, tests, codesigns, and uploads the binaries. This takes multiple hours.
  3. A release manager triggers the generation of the versions.json file. This takes over an hour.
  4. A release manager updates the JuliaLang.org website and posts the Discourse announcement. These steps should be done at the same time.
3 Likes
17

Some other improvements that we need to make:

  1. Currently, the PDF version of the Julia manual is not built automatically; thus, a release manager needs to manually trigger its build. Instead, we should automatically build and upload the PDF manual as part of our normal Buildkite pipeline: Migrate the PDF docs build to Buildkite · Issue #198 · JuliaCI/julia-buildkite · GitHub
  2. Currently, Juliaup hardcodes version information. Eventually, we would like Juliaup to use the versions.json file: Use the published `versions.json` instead of listing versions in source code? · Issue #131 · JuliaLang/juliaup · GitHub

Help is welcome on both of the above-linked issues!

2 Likes
18

One could presumably use a different trigger for Buildkite than a tag, and then the build process could actually generate the tag once everything is done? For example, the build process could be kicked off whenever julia/VERSION at master · JuliaLang/julia · GitHub is changed to have a non-prerelease value in it. I do something similar with the package butler, where the trigger is not a tag, and then the automated build process does things on a branch, and only when everything has finished and it is known that the build succeeded and everything was properly deployed is the tag applied. In general that seems a more robust approach to me. One can never really know whether a build really will work or not, so applying the tag as the last step as a “success, it worked” step can completely prevent a situation where a tag was created, something breaks, and then one has to delete the tag again.

There are obviously a lot of steps that take a long time, but it seems to me that one could probably rearrange things such that the “signal” events all take place at the end: 1) create the tag, 2) upload (not generate) the versions.json, 3) push the things to Juliaup that make a new build visible to it.

It is probably a fair bit of work to pull that off, but I do think it would be nice to have that :slight_smile:

Another thing I’ve been thinking is that maybe it would at some point also make sense that nightly builds are produced in the same way as regular release builds, just with a pre-release tag? That would have two benefits: a) the full release process would be exercised every night so if there are problems it would be detected early, b) at least for Juliaup it would be nice if nightlies could be identified just like any other build with a semver.

3 Likes
19

The tag needs to be made before Julia is built. When Julia is built (i.e. when the make command is run), part of the build process extracts the commit being built and checks whether or not that commit corresponds to a tag. If the commit being built corresponds to a tag, the Julia startup banner will list the tag version as the current version of Julia. If the commit being built does not correspond to a tag, then the Julia startup banner will list the commit itself, as well as the distance between the commit and the last feature freeze.

So there are quite a few parts of the build system that depend on the tag being made before Julia is built. I’m not saying that it’s impossible to switch to a different system, but it would take quite a bit of work to make those changes, and the current system works very well, so I’m not sure if there’s an incentive to make such major changes.

If the only issue is that people see the creation of the tag and confuse this for an official release announcement, then we can address that with better documentation and explanations, not with refactoring the entire build system and CI infrastructure.

2 Likes
20

it was not listed on 6th