Next Julia LTS; when?

General Usage
1

Julia 1.6.4 and 1.7-rc2 releases seem imminent, both have 0 issues on their milestones.

I know it’s been stated Julia 1.6.x will be the next long-term support version (LTS), but it’s not yet declared such officially (at the download page). And at least I would rather want 1.7 as an LTS (or both).

There seems there was no reason to wait for 1.6.1, 1.6.2, etc. or 1.7, so I wander why not declared sooner.

You could say everybody is using 1.6 anyway (I guess nobody is using 1.0 LTS anymore, and few 1.3), and that’s the reason to wait for 1.7.

What do people read into LTS? Just the literal meaning, will be "long-term support"ed, or more, it’s been tested for a while? For me 1.7 could be LTS, as that’s what you would use anyway and if there are bugs you can depend on fixes to it getting backported.

If we go with 1.7 as LTS we have all the benefits of 1.6, plus the changes of 1.7. Julia 1.6 was a much larger release than at 1.7 (or was indented to be, maybe it’s still a much smaller change), but it has dragged on for 5 months over the deadline. I think it’s well tested already, by me and others who live on the master edge, and as 1.7-rc1.

I could list some concrete pluses of 1.7, as in new syntax, but want to hear what others have to say.

Since we’ve waited this long to declare, can we at least wait a few more days after 1.7 released to see if people like it. Many may not have tested it (despite the RC, release candidate) and will then.

2

Nothing has changed from the last time you asked this a month ago.

3 Likes
3

That question (and most answers) was about a possible Julia 2.0, and general future of Julia. Julia 1.7 is a non-breaking release and wasn’t discussed really in any answers there.

4

Still, nothing has changed in regards to the LTS plans in the past month. 1.6 will become LTS when 1.7 is released. This hasn’t changed since this thread.

6 Likes
5

This feels like it’s been answered an awful lot of times. The new LTS will be 1.6. When? When 1.7 is released. Why? Because that’s the documented procedure and the logic is that the current stable release and the LTS should not be the same release. If people want to start acting on Julia 1.6 being the new LTS already, please feel free to do so. It’s literally just us calling it LTS that will change.

10 Likes
6

Thanks for answering/clarifying when, it was puzzling why not already. I see it now in the procedure:

Realistically, however, we don’t really have the capacity to maintain more than a few active backport branches at a time.
[…]
A long term support (LTS) branch (currently release-1.0): an older release branch that will continue to get applicable bug fixes for as long as it continues to be the LTS branch.

I took that as 1.0 is the older LTS, not as a promise/requirement that the latest LTS wouldn’t equal the latest stable release (for a short while), and the “logic” for that impossibility seems, well illogical.

I would like to hear what actual current LTS users want (or potential LTS users).

Julia 1.6 as LTS, is basically a mistake in my view, might lead to questions like why do I get inconsistent (floating point) results between stable and LTS (reason, because of the different RNGs), why doesn’t this are that syntax that works in 1.7+ work, such as x√y, .&& and .|| or:

julia> −1
ERROR: syntax: invalid character "−" near column 1

Your words too:

The vast majority of people should be using whatever the latest Julia version is, not staying on the LTS.

You need to backport to 1.7 anyway, it would ease the burden if it were LTS. When 1.7 wasn’t yet released, the 1.6 LTS plan seemed reasonable, less so when 1.7 is around the corner, plans can change. It seemed like you were delaying taking action for some reason.

Packages should support whatever earliest Julia version they can conveniently support. If that’s the LTS, great; if not, that’s also fine.

That’s my major disagreement. I think there will be push to support the current LTS by the package ecosystem, so (those) packages lose out on new syntax. Compat.jl can take care of other changes between 1.6 and 1.7.

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.

Those people may be stuck at 1.3 or older, and want to upgrade to 1.7 rather than 1.6.

There seems to be some misunderstanding that the LTS is better to run for some reason, which is very much not the case.

So there’s really no promise an LTS well tested (while yes 1.6 and 1.7 are) or for a long time (let alone bug-free), only that it will be supported for a long time, so that alone is not ruling out 1.7 as LTS.

8

Nothing is stopping them from doing so when 1.7 is released though? Always wanting the newest features is very much contradictory to having to stay on LTS from my POV.

By the time 1.7 is released, 1.6 will already have had about half a year of running production code as well as 3 minor releases with bugfixes (some of which were backported from 1.7). If that’s not an indicator of greater stability than 1.7 (an as-of-yet mostly untested & unreleased version), what is?

LTS means “this version is stable and will have backports when you find bugs in it, even 2 years or more after the version was originally released”. It does not mean it will receive new features or bugfixes for those new features. If they want to run 1.7 because they want to use features from it, they’re free to do so - but they have to accept that they won’t receive bugfixes for 1.7 once 1.8 releases.

3 Likes
9

No, it doesn’t, on neither count. The length of long-term support has never been stated as far as I know, and that’s a separate very good question. I would really like to know! For a long time would be ideal (if 1.7, see my updated answer you commented on regarding syntax and RNG), for a SHORTER time would be ideal if 1.6 (so that a better version would be chosen as LTS to replace 1.6, since two concurrent LTSes have been ruled out as too much of a burden). And all of the large and tested 1.6 changes are in 1.7

If you ran 1.6 in production you didn’t really care about LTS, but you’re right it might be more stable. You can’t prove Julia 1.7 unstable by absence of testing, and it’s actually been tested by PkgEval.

“wanting the newest features” isn’t contradictory to me, always wanting them, yes. LTS is about the future support. I was asking what people really read into it, you clearly read stability and tested into, which isn’t promised.

Please do not declare 1.6 as LTS as soon as 1.7 is released, give it at least a week. People going on implicit LTS promise can handle it a bit longer.

10
  • Floating point results have never been guaranteed to be equivalent between releases, expecting them for two different LTS releases seems very weird to me. There would very quickly be no new versions if such a guarantee existed.
  • Likewise, RNG is documented to be allowed to change in minor and bug versions and again expecting them to stay the exact same between LTS versions is expecting a lot of stability from a free product with volunteer maintainers. It would also mean not fixing bugs regarding RNG, since those very often by their very nature have to change the stream of generated numbers.
  • Expecting new syntax in a LTS version that isn’t even in the most recently officially released version again seems like wanting new features without thinking of what it means to run an LTS.

I think there’s a little disconnect here between how e.g. Ubuntu does their LTS releases and how julia does it. In the case of Ubuntu, they announce their LTS well ahead of time and have their newest release be feature and LTS release at the same time. In contrast, julia takes an approach of first releasing the feature release, having the community & package developers find new bugs to fix and only then (after the initial bugs have been ironed out) saying “ok, this is ready for LTS now”. There’s no need to do this for every release though - else there would be no need for the “Long” part of LTS.

LTS remains LTS until the next LTS is released. If a version is marked LTS and you find a bug affecting you in the LTS version, you can file an issue at any time, say it affects LTS (1.0.5 at the moment) and it should get fixed & merged into a hypothetical 1.0.6 release.

Those changes are in 1.6 as well though, so I don’t get your point here. The features that are exclusive to 1.7 are of course not in 1.6.

You can’t really quote me as saying one thing and then turning around and implying I said something else.

What does waiting longer for declaring a minor version LTS do? 1.6 has been out since march 2021. A week will hardly make a difference here.

1 Like
11

I have the impression that all your points will apply to whatever pair of versions 1.x and 1.x+1, no? When 1.8 gets an exciting feature we will be asking the Julia maintainers to not declare 1.7 as LTS and instead wait for 1.8?

Personally I don’t read much into “LTS” more than “release that will get bugfixes for the foreseeable future”.

5 Likes
12

Not really, there are many special situations with 1.7. We’ve had one RNG before and now a new one (and I fell responsible since I suggested it). That’s a change since 2012, and I do not expect we ever change (or at least hope, I can hardly see we can go faster, so only reason would be if it turns out to have a flaw).

Syntax additions are rare, we have e.g. (were judged technical breaking changes?):

  • A backslash (\) before a newline inside a string literal now removes the newline while also respecting indentation. This can be used to split up long strings without newlines into multiple lines of code (#40753).
  • A backslash before a newline in command literals now always removes the newline, similar to standard string literals, whereas the result was not well-defined before (#40753).
julia> [1 ;; 2]  # in Julia 1.6
2-element Vector{Int64}:
 1
 2

julia> [1 ;; 2]  # in Julia 1.7
1×2 Matrix{Int64}:
 1  2

When you use the new syntax, do you (@PetrKryslUCSD) want to debug your students code, who might have used the LTS or vice versa?

We are converging on the best syntax, Julia was already very good, but such rare edge cases could be maddening, since they are rare.

That’s not what I’m saying. There wouldn’t be two LTSes at the same time, I had in mind e.g. 1.6 LTS and 1.7 or LTS and 1.8 etc. Yes, RNG is documented to change, but surprising to some, and you shouldn’t use it in e.g. your tests (rather StableRNG), but plausible people may ignore the warning they didn’t read. This affects integer code too, so people will possibly ask why different random streams. For floating point, people shouldn’t rely on the same, but I only recall one surprising thread on discourse where results were obviously different (i.e. on a graph). We would plausibly see such more often across the 1.7/1.6 LTS boundary.

“Expecting new syntax in a LTS version” if you don’t use it you will not likely be exposed to possible parser bugs since added the new syntax. And I think such code has low possibility of breaking, so I’m not worried for 1.7 for hat reason, only because of the divide, a people issue.

I looked into what other software does for LTS, and it can be as low as 1 year for Firefox (i.e. its JavaScript is included, not sure if it’s handled differently), and their LTS versions come on a schedule (possibly they’re more careful for the prior release, as with Ubuntu). Julia 1.7 was at least supposed to be a time-based release, much smaller change than for Julia 1.6. Yes, it could have bugs, they will be fixed.

Node.js has 1 year of “Active LTS”, whatever that means, but yes, then an additional “Maintenance LTS” for 1.5 year, but yes, to-be-fair, 6 months until “Active LTS” starts for 2.5 years of LTS (in 3 years for each release until EOLed). Releases | Node.js

LTS release status is “long-term support”, which typically guarantees that critical bugs will be fixed for a total of 30 months

13

These are really minor things and not particularly special about the step from 1.6 to 1.7; you will find similar differences between any pair of Julia minor versions.

The only feature I see in 1.7 that could possibly be worth delaying the LTS for is the not unpacked registries, since this can have a huge usability impact in certain environments.

On the other side of the equation is the fact that the current LTS doesn’t have artifact support (Julia 1.3) and it’s becoming really difficult to support packages with (direct or indirect) binary dependencies for Julia 1.0-1.2. For one concrete example, this Julia 1.0 CI failure is due to CodecZlib failing to build on Mac, an indirect dependency three levels below my package.

2 Likes
14

If you wait there’s no difference, but if you don’t wait, and choose 1.6 as LTS sooner or later and regret it and want 1.7 (or 1.8) as LTS, you need to maintain two LTSes. And users who choose the older LTS will have all the same problems as with only 1.6 as LTS, unless you undo that LTS choice, and then it’s not much of an LTS…

1.x is an LTS in name only, 1.0.6 has been ruled out. So most are on latest version, some on 1.3 for Cxx.jl , in that sense 1.3 is a LTS replacement. Cxx.jl is not yet supported on 1.6, if it gets supported on 1.7 then it will divide the package ecosystem. You would either avoid using Cxx.jl even if you could use it. And if you use it, others can’t use your package as a dependency. Cxx.jl was a favorite of mine, and I like all to benefit in case it gets supported again.

15

Sorry: why am I @ed here?

16

Don’t worry, that won’t happen :wink:

1 Like
17

That’s also not what I’m saying, sorry - I must have missed a “stay the same” there. What I was talking about was expecting the bitwise floating point results and RNG streamsto stay the same for two different LTS versions.

I know well about people expecting RNG to never change - there are a number of threads on this very forum where I advise people not to rely on it and where I link them to the relevant section of the docs mentioning that it’s not a good idea to do so (as I’ve written that particular warning in the docs).

The last julia LTS (1.0) was released in 2018 - so that’s more than 3 years(!) of LTS. I really don’t get the kerfuffle with 1.6 vs 1.7 here, except if you really, really, really want to have a feature of 1.7. Heck, if it’s based on features, we might as well wait until julia has a tip-top, perfect, not to be changed static compilation story.

I don’t understand your point here. At any point, there is only one LTS. Right now, that is 1.0.5. With the release of 1.7, the new LTS will be 1.6.4 and 1.0.5 will cease to be a LTS version. Users can still choose to run 1.0.5, they just won’t get bugfixes from the upstream project. If they want that, they can either choose to run on the most recent stable version (which will be 1.7) or run the new LTS version (which will be 1.6.4).

There’s no reason to suspect that 1.6 will be a “shorter” LTS than 1.0 has been. I also don’t get why we’d regret it - there will always be a newer version with more features, bugfixes, etc. so “waiting a week” does absolutely nothing except delay things.

So you want to wait because you hope that in one week suddenly Cxx.jl works again on 1.7…?

18

OMG, please stop. Julia 1.6 will be become the next LTS when 1.7.0 final is released. That’s it. Stop the endless hand-wringing about this.

18 Likes
19