My concern is the package developers, first, and not misleading LTS users.
Already some developers feel the need to support 1.6, because it’s the LTS, and it’s not a huge burden, but it gets harder over time, why I want 1.6 LTS deemphasized or dead (it already is, but people may not realize it). I wrote higher up in the thread, just don’t, don’t feel the need to support anything other than the latest version, and 1.10, since it will likely become the LTS.
It’s reasonable to test on 1.10 in case it becomes the LTS, but it will become problematic to test the latest version of your package on it. So then my new recommendation is just support and test on 1.11 when it gets released.
I would want that many (doesn’t have to be all) packages can easily support 1.10.
Yes, they want to be cautious, only upgrade for security or critical bug fixes. But such fixes aren’t limited to Julia, such fixes may also be needed in packages. And it only takes one such packages that only support 1.11 for this to become a problem.
I’ve marked Stefan’s response above as the “answer” to this topic — that’s about the closest to an answer as is possible at this point. It’s not definitive because the decision of what version to tag the LTS is a consensus process amongst the committers and release managers that weighs many tradeoffs.
You might see the tradeoffs differently. And that’s ok. And you can ask for more weight to be given to some particular points that are important to you (like your desire for the package ecosystem to use public more fully) as you have here. Others can and will have different priorities — and it’s not very helpful to try and guess what those priorities may be on their behalf.
This conversation seems to be starting to circle, so let’s plan on bringing this to a close in a few days.
Would it be possible to accelerate the release of Julia 1.11 by releasing it with only the public keyword as a new feature and delaying other features planned for Julia 1.11 to a later version? Thus, the LTS version could be a version that includes the public keyword without having to wait so long.
No. This is always a tension. See, e.g., what happened with v1.6 and v1.7. And there are just as likely to be other features that others think are more important (e.g., dynamic scopes or Main.main or annotated strings or using nontoxic mushrooms as identifiers).
One consideration about LTS and new features that I think is relevant is that you probably don’t want an LTS to “age” very quickly — meaning that it would be nice if the package ecosystem were likely to support the LTS for a while. But if there’s a killer feature in Julia version LTS+0.1 (the minor release after an LTS), package developers will stop supporting it.
I’m reminded of Python 3.6 and its introduction of f-strings. This was a relatively simple addition to the language, but it improved the ergonomics so much that a lot of developers (including myself) immediately switch to requiring Python >=3.6 just because they wanted to use this one silly little feature of the language. So anyone on 3.5 was just out of luck when I introduced any bug fixes after that point — not because it would actually be difficult for me to support that version, but just because I don’ wanna.
So the question for (the revived portion of) this thread is: Is public such a killer feature? Personally, I don’t see it, and am likely to continue supporting earlier Julia versions for some time.
I see public as more than just a feature. If you have some old code like:
a=0
b="hello"
f(;a=a, b=b)
it would just be old fashioned, but the way that I understand public it would actually be wrong if for example the package HTTP did not declare the request method as public in Julia 1.11. So if I was the maintainer of a package like HTTP I would be compelled to react in order to be conceptually compatible with Julia 1.11.
My reaction would depend on how popular LTS is among users of my package. If some of my users use LTS, then it would make sense to use Compat, if not then I could just create a new version that uses the public keyword and leave LTS users to make do with old versions of my package.
For this reason I am interested in the second question in the OP - how many people are actually using LTS? No-one in this thread has said that they use LTS. Can anyone link to any posts on discourse where people say that they really use LTS?
It’s worth noting that package downloads underrepresent the very sort of user that would use the LTS — they’d similarly be unlikely to upgrade packages (or add new ones). They’d surely have glacially frozen manifests that have long since been instantiated.
I am at a conservative workplace where I have to fight to even be allowed to develop in Julia. R and Python are endorsed instead. I use Julia 1.8 which was new when I started. I develop locally on a Windows laptop and I have a Linux server that the IT department controls with the same Julia version installed. If and when there is a new LTS version declared, this would nudge me to take up the battle with IT to install this Julia version to the server. Until then I will let things be the way they are.
Worth noting, public can have impact long before it’s in a LTS. The point of public is to allow automated analysis of access to non-public objects in other modules. Once someone creates an Aqua.jl test to detect violations of the public interface, CI might run that test only on Julia 1.11, but the observations it reveals will generally be applicable to all supported Julia versions. Consequently the main benefit of public–as a tool to help the community detect and reduce usage of private APIs–could be realized long before public is in an LTS. Moreover, it would improve packages even for people who are still using a Julia version without public.
A second point is that I suspect it might be overly optimistic to imagine that public is going to have dramatic overnight impact. I’ll guess this is going to take some time to propagate through the ecosystem, as disentangling packages from internals will not be trivial. For example, I suspect that most packages are still not using Aqua in their tests, and I suspect that wider adoption of Aqua seems likely to have greater beneficial impact than public will have on its own. If you’d like to contribute, rather than worry about the LTS, consider submitting PRs to packages to adopt Aqua.
I hope this lets you rest more easily about the LTS issue.
Note that if you have write access to any directory in the filesystem, eg $HOME, you can effectively use whatever Julia version you like. OTOH if you don’t have write access, then installing and upgrading packages itself becomes difficult.
Out of curiosity, have the companies that use Julia and the main developers of the large Julia Github organisations been asked whether they would prefer 1.10 or 1.11 to be LTS?
No! It doesn’t since the easiest way to support 1.10 and 1.11 is to NOT use public, I think it may get ignored, not adopted, until the next after LTS. I want people to use it! Or if adopted, then LTS users forced to use packages up to about 2024, but losing out on 2025 etc. packages, so makes it less helpful to have a new LTS, and maintain it for years.
Not automatically, it would stop improving for those users, unless you add burden to (almost) all package developers.
There’s one solution, 1.11 will become 1.12, freeing up 1.11 for LTS. Actually nothing requires adding 1 to version numbers, there can be gaps, and only even used to leave the odd numbers as potential LTS versions.
I did not know that - thanks. I do have enough privileges to instantiate environments, i.e. to install packages. However, I am not sure circumventing IT this way (upgrading Julia behind their back) will increase the chances of wider Julia adoption at my company.
I think it would help to clearly outline what the typical/expected audience of Julia LTS versions is – and put it somewhere to the docs. My intuitive understanding is that LTS users are those who are extremely conservative, and unlikely to upgrade many packages at all. So, it rarely makes sense for a package dev to spend significant effort to support julia LTS.
Would be nice to clarify this situation “officially”, which can help avoiding or steering these discussions every time new features is added.
Regarding 1.10 or 1.11 as LTS, I think it has to be 1.10.
Julia 1.11 introduces some new changes that will need some time smooth out. In particular, Pkg and REPL are no longer in the system image. Those packages also currently introduce invalidations.
As a package developer, the currently supported Julia versions are the only ones I test my packages against.
I sort of agree that public will be more widely adopted if landed in the LTS, and that it will bring, in the long run, many benefits. Release cycles follow their own rules which I have nothing to say about, but 1.11 could just be 1.10 + public, and that become the LTS. Not having it in the LTS will effectively hold its usage back for a while.
