Sure, but that same argument of yours says “LTS is irrelevant in the first place”.
To give an example: At my day-job we need to schedule what java version we use for what projects. For various reasons, changing that is always an annoyance and needs some validation time (and sometimes it also needs adjustments, validation is not just for fun). So it is nice to be able to plan all that beforehand!
And we actually have actually run into JVM bugs and needed an emergency patch, which we could yolo-deploy without large validation delays. Being on an LTS inside the support window guaranteed that such a patch would be forthcoming (in reality the patch came before LTS became relevant, so I’d classify that as a near-miss).
There is always an LTS we can pick that will be supported for a reasonable timeframe. This is a guarantee that is only possible with overlapping LTS support timeframes.
I’m not sure that the whole LTS effort is worth the amount of labor, for julialang specifically.
But if it is worth doing at all, then I think it is worth having overlapping support windows for graceful roll-over.
Introducing a new keyword to the language is definitively 100% no-doubt-about-it a new feature.
Features are not backported. This isn’t just because that’s what SemVer says, but it’s also because net new code can and does have more bugs than battle-tested code… and it’s also a very meaningful simplification in how to understand a given release and its supported featureset.
Sometimes the line between bugfix and feature is indeed blurry, but this is not one of those times.
Just to clarify, when I said documented, I mean documented in the official online documentation (at docs.julialang.org), and NOT that there is a docstring. Indeed, a docstring can document non-API functionality. But if something is in the official docs, then it’s API unless stated otherwise. Same goes for packages.
Given that there is some leeway in choosing which version of Julia is LTS, one criterion for choosing which version is LTS might be which version contains features that can potentially change the way developers interact with Julia.
Is Julia 1.11 expected to contain any new features that could potentially change the way developers interact with Julia?
It’s worth being explicit about what the S in LTS means — the word “Support” is pretty laden with many meanings. In this case it’s quite limited and concrete: it means that there’s a branch onto which backports can land and from which a new patch release might be cut. That’s also exactly the support that the most recent release gets.
So perhaps that is a reason to more officially signal the next-LTS before its official designation. For example, with the 1.6 release, it was informally signaled in discussions here as the next-LTS before it was officially named when 1.7 was released. On the other hand, it is helpful to get a sense of a given minor release’s stability before designating it as the LTS, which is why it’s been pragmatic to wait on naming the LTS.
Barring bad (thus far unseen) problems with the release, Julia 1.10 is very likely to become the new LTS once we’ve gotten a couple of point releases out for it. So far there’s a bit of a kerfuffle about artifact hash mismatches making 1.10.0 unusable for Windows users not using Developer Mode, but that’s a very solvable problem that’s being addressed. Aside from that, the feedback about 1.10 has been quite positive, so it’s looking good so far.
Sure, but it also means: If a bad bug is discovered, then there will be another release. If people report bad bugs for most recent patch-release of LTS, then they won’t be closed on github because “incidentally fixed on latest release / master”.
“bad bug” means something that is hard to workaround. E.g. a crash due to llvm-bugs. Or in the jvm world, Loading... where the workaround (barring the patch) was “disable C2 via command line option or pray that you don’t trigger the faulty optimizer path” (with the obvious performance impact).
Are there statistics out there to try to tease out how often used LTS is versus other releases? Like do the package download stats provide the Julia version which is used to install the package?
AFAIK there are no such explicit guarantees for Julia. What you get with Julia LTS is the possibility that the branch will get some backports (as opposed to all previous versions), but no timeframe.
I think it is important to address the concerns of LTS users, but then it would be good to hear from them directly instead of speculating. I am wondering what fraction of participants in this discussion (or any of the other “is 1.x the new LTS?”) actually use an LTS.
@foobar_lv2, @Palli, do you actually use 1.6 as your main Julia version?
I no longer use 1.6, I always use latest stable, and/or master.
My point is that package developers should disregard 1.6, but also make packages for 1.11 which means disregarding 1.11 1.10. 1.10 without “public” shouldn’t hold back good software development, or make it any more difficult to support 1.10 as it.
What’s the point of LTS? It’s backwards-looking, I can use packages already developed, but also to some degree forward-looking, I can expect (security) updates for some (unspecified) “long time” (for Julia, maybe also packages), at least more than a year, or not just until next stable release.
If I were considering an LTS for say the next two years (e.g. developing my own software), then I might want to use latest packages developed in say the next year. Then the package ecosystem has a problem.
That will certainly be more helpful than 1.6, but without “public” it seems we might as well declare 1.9 LTS and drop 1.6.
I had a typo (now fixed), I meant “make packages for 1.11 which means disregarding 1.10”, meaning good packages for 1.11 use public (where applying) and by doing such disregard 1.10 users by default, or make work for themselves to support older releases too, that would be avoided if LTS has support for public.
Do you think “public” will actually not be used much in packages as opposed to Julia itself (since there it’s problematic to export)?
There are always new goodies that folks will want from newer releases (see, e.g., v1.7). That’s a good thing. That’s something you explicitly sacrifice in choosing to use any LTS of any software.
Yes, many packages choose to use Julia’s LTS marker to drive their own development practices. But that’s also why Compat.jl exists.
Generally if you need a feature present from Julia 1.11, you will need to either lower bound the Julia version in compat or use Compat.jl if possible.
This does not “disregard” 1.10 users, because once 1.11 is released, they can (and should) just upgrade.
I don’t think this is relevant to the present discussion. Every release introduces new features, which some packages end up using. That’s how software works — otherwise there would not be any point in making new releases. We have versioning and compat bounds to deal with this smoothly.
Also, this is pretty much irrelevant to the recurring “is 1.x the new LTS” discussions, of which you have started quite a few, for reasons I still don’t understand.
Maybe I make to big of a deal out of this, currently less than 1.4% of packages (Direct (132) Indirect (4640) users) have Compat.jl as a direct dependency, and from now on, close/r to a 100% might need to, annoying to add and I’m not sure how many even know of its existence, but now they need to, and add, or possibly tools can automate it?
All those that do not will make the LTS second class (a good reason to not use it from now on for new code; then an argument sort of to not release a new LTS…), more so than in the past. Usually the same syntax/keywords have worked on latest vs. LTS, and now that is broken. It feels worse than some obscure (e.g. LinearAlgebra) added function that few need.
Right most can and should, and how does that not disregard 1.10 users? I.e. those that want to use 1.10 LTS? Current 1.6 LTS users can “disregard” the possible new LTS (1.10 likely), nobody is forcing users to opt into it.
It seems the new possible 1.10 LTS (assuming public not added) will be dead-on-arrival, with people not wanting to use it. It’s not in users hands to add Compat to packages, except by bugging the package ecosystem developers to add it (or make a PR), or even worse a separate branch (that will get left behind).
Just to clarify, if you are using Julia 1.x, all packages that are currently working on it will continue working the same way forever. Some will get updates, and at some point some of these would require 1.y > 1.x, then from that point on you will be missing updates. That applies to all Julia versions, LTS or not.
The only difference for LTS is that you get some backports. The users who stick to LTS are low risk tolerance, meaning that they don’t upgrade their packages for no good reason either, so in all likelihood they lose nothing by missing updates. They update to the new LTS when it comes out, at which point they presumably update the packages, review package API changes, run their most extensive test suite, etc.
There is no way one can keep up with all package updates and stick to an older Julia version, LTS or not, regardless of Compat. Some packages will make an extra effort to support the latest LTS, some won’t. This decision is up to the package devs.
Sure they can, but in all likelihood they will want to update.
There were a lot of new features between 1.6 and 1.10 which I guess almost all LTS users may want to use at some point, but we shall see.
To be frank, I still don’t get what you want from this discussion. Make every release an LTS? (Because you opened a similar topic for almost all recent releases). Or make 1.11 the next LTS just because it has public?
I also find it interesting that you are asking so much about the LTS when you said you do not use it. I live on the bleeding edge… once something hits RC or beta then I switch to that. I do not look back at or care about prior releases anymore.
Is your concern that supporting an LTS slows development of new language features? Is your concern that the LTS is inferior to the latest release, so that people who need that long-term stability will not choose Julia over something else?
