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.
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.
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.
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.
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.
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?
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?
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.
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.
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.
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.
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.
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.