Someone mentioned on Slack yesterday that many optimizations in Diffractor rely on changes introduced in 1.8, so again there might not be a clear cutoff point here (as Diffractor is still under heavy development and presumably will continue to be after release).
1 Like
I canât provide the answer, but Iâd like to point out that the contenders for being a LTS are currently 1.0.5, 1.6.1, and 1.7.x.
Oh dear, I really hadnât meant to kick off a discussion like this âŚ
After reading the v1.7 release notes I just though âwow, this looks like a big relelaseâ, and I was wondering if the the plans of the dev team regarding LTS had changed, and I remembered hearing that Diffractor would require v1.7 (but based on what @nilshg wrote it looks like itâs not that clear-cut). I fully support @simeonschaubâs argument that at some point one has to be pragmatic and âbite the bulletâ. The current situation with v1.3 being a kind of âde-facto LTSâ (due to artifact support) certainly shouldnât be dragged out much longer, IMHO.
1 Like
The plan is still for 1.6 to be the new LTS. There are always features in new releases that someone would like to have in an LTS version. Aside from the manifest format, which is being backported to 1.6, none of these seem like show-stoppers.
The vast majority of people should be using whatever the latest Julia version is, not staying on the LTS. There seems to be some misunderstanding that the LTS is better to run for some reason, which is very much not the case. You should only be using the LTS if itâs very expensive or risky for you to go through the process of upgrading, which is not the case for 99% of users. People who need the latest and greatest in machine learning capabilities are very much not the target audience for the LTS release and should be using whatever the current stable Julia version is. Packages should support whatever earliest Julia version they can conveniently support. If thatâs the LTS, great; if not, thatâs also fine. For example, for many packages Julia 1.3 has been a lower bound for a long time because it introduced artifacts and multithreading. Even though that wasnât the official LTS, it was a fine lower bound for packages to have.
In hindsight, the amount of time spent on the 1.6 release was probably a mistake and we should just do timed releases like we normally do regardless of whether something is going to be an LTS or not. And we should probably just do a timed LTS as well on a two year cadence. So whatever 1.x release is first cut in 2023 would be the next LTS.
29 Likes
Although I kind of feel like a one year cadence might actually make more sense. Julia 1.0 didnât get all that many release â partly because the infrastructure needed to test new releases stopped working for the 1.0.x series, which might end up happening again. Two years is still an awfully long time in Julia development at this point.
8 Likes
As already mentioned, the problem with determining a LTS is that almost every new julia release is so much more awesome than its predecessor. Looking back I felt that each of the following releases 0.5, 0.6, 0.7/1.0, 1.3, 1.5, 1.6, 1.7 was a game changer in some way and each time I wondered how I managed to get work done with older julia versions.
4 Likes
The only thing from 1.7 Iâd really miss in 1.6 LTS would be the libblastrampoline stuff. Although targeting more of a niche, I compare it to the introduction of artifacts in 1.3.
Having said that, I must admit that I donât really care too much about LTS versions anyways. Living on the bleeding edge is too cool 
3 Likes
From my point of view the only reason to delay the LTS would be the non-unpacking of the registry, as that can have a huge usability impact in certain environments. The main reasons I can see for not delaying the LTS is to finally get LTS support for artifacts and the fact that 1.7 has a new manifest format that 1.0 doesnât know about and probably doesnât handle gracefully. I suspect the latter would make the LTS upgrade quite a bit more painful than it should have to be.
2 Likes
This will indeed make life much easier for people working on systems with network-shared home directories. Would compatibility with this be back-ported to v1.6 as well (if 1.6 becomes LTS) or would there just be two parallel local instances of the registry?
The new Manifest format will be backported to 1.6 though, so that doesnât change anything in regards to LTS.
3 Likes
If 1.7 were to be the next LTS, the LTS upgrade would be directly from 1.0 to 1.7 and backports to 1.6 donât come into play.
Yes, what I meant was that no matter if 1.6 or 1.7 becomes LTS, the Manifest from 1.0 will break either way. Since thatâs the case, the Manifest argument isnât relevant to the decision whether 1.6 or 1.7 becomes LTS.
From my understanding thatâs not what the backport means. 1.6 will keep using the old manifest format but will understand the new 1.7 format.
4 Likes
Correct. 1.6.2 will default to making old format manifests, but will recognize and maintain any new format manifests it comes across.
1.7+ defaults to the new format and will still support and maintain the old format, unless the user calls Pkg.upgrade_manifest()
11 Likes