Is there a good reason to have an LTS version of Julia?

Internals & Design
1

Hi!

I was wondering what is the purpose of an LTS version of Julia today?

I understand that close to 1.0 release, an LTS version would be important because the language was changing very fast. However, given that release process is so stable, is there really a reason to keep supporting very old versions?

My point is that having an LTS version leads to a huge time interval for packages to support new language features. For example, in PrettyTables.jl, I must support 1.6. Hence, any new feature added between 1.6 up to 1.9 (2 years of development), I cannot use unless I take care of the LTS version by using @static if etc. If the new feature would simplify a lot the workflow, but requires a lot of rewriting, I just skip it.

I feel that having something named LTS passes the illusion that the newest version is not stable (something we have, for example, in Debian Stable and Testing), which is completely wrong, IMHO.

I really do not think there is a right answer here. We have languages that supports an LTS version and we have languages that don’t.

7 Likes
2

But note that you don’t have to support LTS in terms of new features, it might be reasonable as a package author to take the same approach as the language itself, i.e. Bugfixes get backported so that people on the LTS receive them, while new features require newer Julia versions.

19 Likes
3

Wait, why?! Don’t see anything wrong with releasing new package versions that only work on newer Julia versions. Those staying on LTS still have earlier package versions – the same versions they had before. Presumably stability is important above all for those using LTS, not getting new features.

7 Likes
4

The problem with this approach proposed by you two is that it leads to a much higher amount of work for the package maintainers in terms of bug fixing and security issues.

For packages with very few people developing (or even one), the only realistic scenario IMHO is either keep using only the features in LTS or do not even support bug fixing in the latest version supported in LTS. The latter would make Julia experience w.r.t it ecosystem bad for users using the LTS.

3 Likes
5

I think the experience is already going to be bad for these people, relative to the rest of us. As @aplavin said, if stability is so important to these users, they’re probably not upgrading your package either, anyway.

Given the scarce resource of your development time, I think you can (and should) focus your efforts, and not try to support some hypothetical users that you don’t even know exist.

8 Likes
6

I fully agree! But in this case, wouldn’t it be better to just drop the Julia LTS version? The difference is that the LTS has bug fixes, which will happen only for the language itself and the stdlibs. Can’t we use the same argument: those who want stability will stick with a single Julia version?

7

It seems there are two questions here.

  1. Should Julia have a LTS version?
  2. Should my package backport bug fixes to the LTS?

The first question is legitimate but for other people to answer. The second question is for you to answer and there is good advice above.

3 Likes
8

Often users who want stability still want security updates.

9

Yes! And that is precisely the problem. Notice that some people want stability and others want immutability. For those who want immutability, the Manifest.toml should work all the times. For those who want stability, are the new versions really problematic?

10

I think it is still good in principle to have an LTS version of Julia which will get bugfixes. Otherwise the only way to get those is to get the newest release, which may change additional things that affect maintenance workload.

3 Likes
11

But wouldn’t it be the same with the packages that do not support LTS? I suspect the majority of users use Julia+packages from the ecosystem.

12

I could be mistaken, but I think the likelihood of security vulnerability bugs in packages like PrettyTables is pretty small. And I suspect if you found one, it would be worth the effort for you to backport it, no? But that’s different than feeling the need to make sure every feature works that far back.

There are people that are going to pick a Julia version and stick with it a very long time. I think it makes sense to give those people a specific target version to prioritize, rather than haphazardly landing on whatever version is currently released when they get started. Imagine if a bunch of your users were stuck on 1.5, others on 1.6, and a handful on 1.7. That seems way worse to me.

12 Likes
13

I think this is a fairly compelling argument in favor of having an LTS, if only to corral these kinds of users into a smaller number of versions into some mutually-agreed-upon minor release.

8 Likes
14

To reduce your maintenance burden, one suggestion is to declare a version of your package as the LTS for your package. Then you only need to backport bugfixes to this one LTS version only or you can ask whoever was hit by the bug and is stuck with LTS Julia and LTS PrettyTables to make a PR to backport the bugfixes they need. This is open source so you don’t have to do everything yourself.

1 Like
15

I would just ignore Julia 1.6 LTS. You don’t “must” support it. It’s optional for anybody.

Julia 1.6.0 was released on 24 March 2021 I believe, so a few months left of 3 years of support (if that was intended, but it was never explicitly stated how “long” it is, I believe).

My understanding is that Julia 1.10 will become the new LTS, hopefully soon. It doesn’t make any sense for anyone to use the old 1.6 LTS for new stuff, nor to expect a maintenance burden from the ecosystem.

I would actually want to know how many use the LTS, like a vote, not just download numbers. Maybe there’s no huge need for it. If there is then I would suggest two LTSes staggered by 1.5 years, and the ecosystem only planning to maintain for the latter.

I think it makes sense to expect something (since an LTS offered) but only security fixes for full 3 years, but bugfixes in the newer LTS, i.e. for 1.5 years, if that target accepted. It seems unlikely there will be bugs discovered anyway after 1.5 years of an LTS outstanding, and if you’re on your own.

For the ecosystem this means supporting for 1.5 years, but even that is optional. We can’t expect anything from open source ecosystem (or really Julia).

Note, anyone can pin versions, or just not upgrade. And any versions, not just LTS will work for more than 3 years.

1 Like
16

My understanding is that Julia 1.10 will become the new LTS, hopefully soon

I think it’ll take at least six to nine months, as 1.10 will only be declared as the LTS once 1.11 is out.

1 Like
17

As a side note, since JuliaHub collects information about new installs of every package, it would be nice if it collected information on which Julia version the package was installed. With that one could obtain a clear indication for if an old version is worth supporting or not.

1 Like
18

Just to be abundantly clear here, it’s the community Julia Language Project package servers that collect and expose this anonymized information for anyone to use. JuliaHub is a consumer of this data:

7 Likes
19

Keep in mind that @Ronis_BR maintains a low-level package in the ecosystem:

PrettyTables.jl pretty much has to support LTS because DataFrames.jl supports LTS, or DataFrames.jl wont be able to use anything that get added without 1.6 support.

6 Likes
20

That’s true. Though all we need is DataFrames to work with a version of PrettyTables that supports Julia 1.6. It’s fine if PrettyTables adds new features that are not used by DataFrames in new versions that do not support Julia 1.6, as along as backward compatibility is preserved.

4 Likes