[RFC] Dropping support for Julia < 1.3 in Turing.jl?

Hi!

It seems that the Julia SciML and FluxML ecosystems are moving away from Julia 1.0 and using Julia 1.3 as the new lower bound, e.g. DifferentialEquations, Flux, Zygote, Tracker, NNlib, etc. In Turing.jl, we are considering to do the same since we depend on Tracker by default in the current latest version. We can try to keep “support” for Julia 1.0 either by back-porting bug fixes to Turing v0.13.x, or by making Tracker an optional dependency in the new v0.14.0. But given that many related parts of the Julia ecosystem are moving away from Julia 1.0, this might be an upstream sail so it may not be worth the effort.

I wonder what do people here think about dropping support for Julia 1.0? How far are we from Julia 1.6, the new LTS? And is anyone using Turing.jl with Julia < 1.3 that we need to be aware of?

5 Likes

I think just drop it. Turing on v1.0 is already good. I’d just spend the time making the next LTS great.

12 Likes

I would also suggest dropping it. Those needing to stay on 1.0 should expect correctness for current use, freedom of security issues, but not new features, increased flexibility or performance improvements. Turing being 0.x software I think is a factor as to whether backports are best use of contributor time as well.

4 Likes

I am generally against this as long as 1.0.5 is the current LTS. But I am not a user of Turing.jl at all. It’s just a general comment I make for all packages.

Personally, I always make an effort to support the current LTS version.

4 Likes

Ok, the next release will support Julia >= 1.3 then. If someone needs bug fixes from later Turing versions and can’t use Julia >= 1.3 for some reason, we will look into back-porting then.

1 Like