[release-1.0] Set VERSION to 1.0.1

[ararslan]

Once this is merged, I'll tag and make binaries and there will be rainbows and unicorns and puppies everywhere

[StefanKarpinski]

Should we announce that people should test the release-1.0 branch for a couple of days?

[ararslan]

If you want. I did a PkgEval run and the backports branch had been open for over a month, so I'm not super concerned.

[StefanKarpinski]

It was never announced, which is what we had agreed to do. I think we should announce this on discourse and ask people to test for a few days to make sure that it doesn't break anything.

[ararslan]

which is what we had agreed to do

Not sure what you mean?

[KristofferC]

The discussion is here #27621 (comment)

[ararslan]

Okay, thanks. Been too long since then for me to remember, I guess. https://discourse.julialang.org/t/julia-1-0-1-testing-period/15534

[StefanKarpinski]

Yes, that conversation. Thanks for tracking it down, @KristofferC!

[timholy]

Will there also be a 0.7.1?

[cdluminate]

FYI the julia 1.0.0-0ubuntu5 package shipped with in the upcoming Ubuntu is actually v1.0.0+167 patches from 1.0.1. I'll upload 1.0.1 to Debian when it is released and poke ubuntu guys to synchronize from Debian again.

[ViralBShah]

I believe the original thought was that there won't be any 0.7.x releases.

[ViralBShah]

@cdluminate Does debian/ubuntu also carry all our upstream patches for llvm, libunwind, libgit2, libssh2, etc. along with relevant version of openblas?

[StefanKarpinski]

Will there also be a 0.7.1?

I believe the original thought was that there won't be any 0.7.x releases.

However, if there's a strong argument for a 0.7.1 we could consider it; I don't think such an argument has been made, however. Did you have a reason you wanted it, @timholy? I'm imagining most patches to 1.0.0 should apply fairly cleanly to 0.7.0 as well.

[cdluminate]

@cdluminate Does debian/ubuntu also carry all our upstream patches for llvm, libunwind, libgit2, libssh2, etc. along with relevant version of openblas?

We have not managed to check all patches with the existing Debian packages. Only several patches were picked into Debian's llvm-6.0, see [2] (search for julia). Does that mean I should pay special care to Debian's llvm, unwind, libssh2, libgit2 packages and the patches shipped with by julia?

FYI, All dependencies used to build julia are provided by system except for libuv and libwhich. And these packages keep rolling in Debian unstable. And our packaging repo is here[1].

llvm-6.0-dev/unstable,unstable,now 1:6.0.1-9 amd64 [installed]
libunwind8/unstable,unstable,now 1.2.1-8 amd64 [installed,automatic]
libgit2-27/unstable,unstable,now 0.27.4+dfsg.1-0.1 amd64 [installed,automatic]
libssh2-1/unstable,unstable,now 1.8.0-2 amd64 [installed,automatic]

[1] https://salsa.debian.org/julia-team/julia/
[2] https://tracker.debian.org/media/packages/l/llvm-toolchain-6.0/changelog-16.0.1-9

[ViralBShah]

Yes, LLVM is the most relevant in terms of carrying all the patches, followed by all the other libraries we patch. Also, it is good to match Julia's shipped version of openblas.

The way to know if everything has been done correctly is to run all the tests and ensure they pass. I am not sure if that is done on the debian builders.

[cdluminate]

@cdluminate Does debian/ubuntu also carry all our upstream patches for llvm, libunwind, libgit2, libssh2, etc. along with relevant version of openblas?

Is there anything special with OpenBLAS? We are aware that openblas 3.2 has a severe regression in singular value decomposition.

BTW, in the latest upload of Debian's julia package (1.0.0-3), I linked julia against the virtual packages libblas.so.3 and liblapack.so.3 so that users can switch the BLAS/LAPACK backend via the update-alternatives system. For example

~/D/j/j/debian ❯❯❯ sudo update-alternatives --config libblas.so.3-x86_64-linux-gnu
[sudo] password for lumin: 
There are 4 choices for the alternative libblas.so.3-x86_64-linux-gnu (providing /usr/lib/x86_64-linux-gnu/libblas.so.3).

  Selection    Path                                             Priority   Status
------------------------------------------------------------
  0            /usr/lib/x86_64-linux-gnu/openblas/libblas.so.3   40        auto mode
  1            /usr/lib/x86_64-linux-gnu/atlas/libblas.so.3      35        manual mode
  2            /usr/lib/x86_64-linux-gnu/blas/libblas.so.3       10        manual mode
* 3            /usr/lib/x86_64-linux-gnu/libmkl_rt.so            1         manual mode
  4            /usr/lib/x86_64-linux-gnu/openblas/libblas.so.3   40        manual mode

Press <enter> to keep the current choice[*], or type selection number: 

I can switch the BLAS backend between OpenBLAS and MKL without recompiling julia with this. But julia will print some warnings (e.g. MKL_xxx symbol not found in libopenblas. I haven't investigated into it yet).

[cdluminate]

Yes, LLVM is the most relevant in terms of carrying all the patches, followed by all the other libraries we patch. Also, it is good to match Julia's shipped version of openblas.

The way to know if everything has been done correctly is to run all the tests and ensure they pass. I am not sure if that is done on the debian builders.

Debian and Ubuntu always run the tests before upload, after upload, and even when one of the package's dependencies gets updated.

e.g. https://autopkgtest.ubuntu.com/packages/j/julia/cosmic/amd64

[Petr-Hlavenka]

I'd like to ask if the windows installer could in the pre-install phase check whether the TLS "Easy Fix" update and the Windows Management Framework 3.0 are installed before proceeding with the Julia install? The problem is, many people just forget to install these and then they just let others troubleshoot these missing requirements. It looks like the win7 will stay with us for many years.

[KristofferC]

I made a set of release notes https://gist.github.com/KristofferC/b6ffe2b19d05e7719131f7726275a287 using the script at https://gist.github.com/KristofferC/3c0cc686b6004484c1a66d45114b77fc.

It looks at labels from PRs and categorizes them into "bugfix, performance, docs" and generates that to markdown.

[timholy]

Did you have a reason you wanted it, @timholy? I'm imagining most patches to 1.0.0 should apply fairly cleanly to 0.7.0 as well.

The main reason I asked is because we have something like 30 lab-private packages (some of which are pretty complex) that we're still porting to 0.7/1.0, and a few of the bugs in the .0 releases make it a little harder. We chatted about this internally and want to be clear, though, that this is not a make-or-break issue for us. As rough guidance, if this is something that could be done with 0.5-1 day of work, it might be worth it (esp. if others would benefit), but would not be worth doing purely on our account if it's much more than that.

If there's some way we can help, do let us know---I'd call that "putting our money where our mouth is," and I'm not opposed to making that a criterion for deciding whether to do this.

CC @kdw503.

[StefanKarpinski]

There's always the option of making a minimal 0.7.1 with only fixes for the bugs that were making things hard. I'm also not sure how hard doing a larger set of back ports would be. @KristofferC?

[KristofferC]

Writing a script that just tries to backport every commit on this branch to 0.7 would be interesting.

[ararslan]

The time has come, folks.