Julia v1.1.0-rc1, the first 1.1 release candidate, is now available

Announcements
1

Happy new year, everyone!

The Julia developers are pleased to announce the first release candidate for Julia v1.1.0. As usual, binaries are available for all tier 1 platforms—Linux i686 and x86-64, macOS, FreeBSD x86-64, and Windows 32- and 64-bit—as well as Linux ARMv7, at https://julialang.org/downloads. You can find them in the “upcoming releases” section.

As a release candidate, this should not be considered production-ready; it’s intended to give users, especially package developers, a chance to test their code with v1.1.0 before the full release.

Julia v1.1.0 will be the first minor release in the 1.x series of releases. As a minor release, it will contain no breaking changes, only new features, performance improvements, and marginal, undisruptive changes in behavior. The largest difference from the 1.0.x series of releases are that 1.0 will have longer-term support, and that 1.1 contains new features that 1.0 will not have. The most useful reference for the changes is the NEWS file for v1.1.0-rc1, but you can also see the commit comparison with v1.0.3 here.

1.1 is now available by name on Travis and AppVeyor (using Appveyor.jl). We encourage everyone to give it a try and let us know in the issue tracker if you run into any issues.

Enjoy!

34 Likes
2

Amazing! Thank you.

I just noticed a repeated statement in NEWS.md in the Standard library changes section:

  • range can accept the stop value as a positional argument, e.g. range(1,10,step=2) (#28708).
  • range now accepts stop as a positional argument (#28708).

These are points 5 and 19.

4 Likes
3

Going forward after more releases, is it recommended to continue testing on 1.0 or to switch to 1.x only?

4

It’s best to test on both, as 1.0 will have long-term support.

5

Off topic, but shouldn’t it be “the step value” and “accepts step” (instead of stop)?

6

I’m not understanding what you mean. Continue testing what on 1.0 or 1.x?

7

What I meant to ask is whether it is needed to test packages on v1.0 to maintain compatibility with it in the future, or is it enough to only test v1.1, because v1.1 does not have breaking changes, right? So the question was whether 1.0 needs to be tested for packages to maintain compatibility with long term release.

8

If you want to claim that your package works on Julia 1.0 you should test on Julia 1.0.

9

No, the old range syntax was like this:

range(start; length, stop, step=1)

but the new 1.1 syntax is like this:

range(start[, stop]; length, stop, step=1)

So, you can now do all of the following 6 combinations, the second argument being stop unless otherwise specified (very nice!):

  julia> range(1, length=100)
  1:100

  julia> range(1, stop=100)
  1:100

  julia> range(1, step=5, length=100)
  1:5:496

  julia> range(1, step=5, stop=100)
  1:5:96

  julia> range(1, 10, length=101)
  1.0:0.09:10.0

  julia> range(1, 100, step=5)
  1:5:96
4 Likes
10

Don’t get it. The promise of 1.0 was that things would not break till 2.0, so why keep testing 1.0x when 1.1 is out?

11

Check the New language features - ( not in v1.0 )

12

You’ve got the compatibility direction backwards. Something that works on 1.0 will work on 1.1 but something that works on 1.1 need not work on 1.0.

3 Likes
13

Sure. I was thinking on codes that were written at the 1.0x time (me, confusion)

14

That makes sense, but my question was subtly more general than your answer satisfies.

I’m also asking about the more general case when v1.x is released, let’s say v1.2, then it is recommended to continue testing for compatibility with v1.0 and v1.2, since v1.0 is long term. However, because v1.1 is a short term release, is it recommended to drop it from testing and only continue with v1.0 and v1.2 compatibility? Otherwise, the tests would keep getting longer and longer with each version.

It doesn’t necessarily make sense for the Julia package community to explicitly support v1.1 when (for example) v1.0 is long term and v1.2 is the current stable release. So my question is slightly more general, about what kind of compatibility people would like to expect out in the packages.

1 Like
15

I think this really comes down to your preferences as a package maintainer, and how disruptive/how much extra work is required supporting older versions of 1.x Julia (including test run time) becomes for your package as time goes by (e.g. you may want to rely on new language features that make supporting 1.0 difficult or impossible).

I think an entirely pragmatic approach would be to explicitly test only against the latest stable release and whatever 1.x version is the LTS version (this is only my view, primarily as a user of Julia, not a package developer). If the package works on the LTS version, Julia’s adherence to SemVer means that any versions in between the LTS version and the newest stable version should also work (unless you’re relying on undocumented features). Currently the LTS version is 1.0, but (as I understand it) that isn’t set in stone, as outlined by Stefan:

I take Alex’s initial post to mean that 1.1 won’t be a LTS branch, but my reading of Stefan’s comments is that future minor versions (e.g. 1.2) could replace 1.0 as the LTS branch if there is demand for that.

2 Likes
16

That’s pretty cool, thanks for the detailed explanation. I wasn’t aware of the stop option. I always used the range literal to create new instances, but stop is great to avoid bound checks during an iteration. Would be nice to see a range literal which includes it, too, like maybe (1:5:96:100)

17

Looking forward to the final 1.1. Quick question: is PackageCompiler expected to work? Same command that worked with 0.7.0 is failing on 1.1.0rc1 with ‘ERROR: Unexpected format of “Base.julia_cmd()”, you may be using an incompatible version of Julia’. This is with the latest version of PackageCompiler (0.5.1 installed this morning).

Thanks,

Dara

julia> using PackageCompiler

julia> build_executable("hello.jl")
Julia program file:
  "/tmp/hello.jl"
C program file:
  "/test/julia-1.1.0-rc1/pkg/packages/PackageCompiler/jBqfm/examples/program.c"
Build directory:
  "/tmp/builddir"
ERROR: Unexpected format of "Base.julia_cmd()", you may be using an incompatible version of Julia
Stacktrace:
 [1] error(::String) at ./error.jl:33
 [2] build_julia_cmd(::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing) at /test/julia-1.1.0-rc1/pkg/packages/PackageCompiler/jBqfm/src/static_julia.jl:213
 [3] build_object(::String, ::String, ::String, ::Bool, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing) at /test/julia-1.1.0-rc1/pkg/packages/PackageCompiler/jBqfm/src/static_julia.jl:239
 [4] #static_julia#1(::Nothing, ::Bool, ::Bool, ::Nothing, ::Nothing, ::Nothing, ::Bool, ::Bool, ::Bool, ::Bool, ::Bool, ::Bool, ::Bool, ::Bool, ::Nothing, ::Bool, ::Bool, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::typeof(static_julia), ::String) at /test/julia-1.1.0-rc1/pkg/packages/PackageCompiler/jBqfm/src/static_julia.jl:172
 [5] #static_julia at ./none:0 [inlined]
 [6] #build_executable#22 at /test/julia-1.1.0-rc1/pkg/packages/PackageCompiler/jBqfm/src/api.jl:104 [inlined]
 [7] build_executable at /test/julia-1.1.0-rc1/pkg/packages/PackageCompiler/jBqfm/src/api.jl:104 [inlined] (repeats 2 times)
 [8] top-level scope at none:0

shell> cat /tmp/hello.jl
module Hello

Base.@ccallable function julia_main(ARGS::Vector{String})::Cint
    println("hello, world")
    return 0
end


end

julia>
18

Happily, PackageCompiler has now been updated to fix this issue: Unexpected format of "Base.julia_cmd()" compatability issues with 1.2.0-dev.60 · Issue #162 · JuliaLang/PackageCompiler.jl · GitHub

2 Likes