It seems obvious 1.7 to me should be the next LTS, as I thought it would. We’ve waited this long, and I believe there’s consensus by now that 1.6 is a good release, so why not go with that?
So what are the pros and cons for 1.6 vs 1.7 (or later) for LTS?
It seems you could backport all of 1.7+ good features to 1.6 (you technically can for each individual one, but there are reasons you don’t want to).
I’ll first highlight some pros of Julia 1.7, from NEWS (now in HISTORY on master):
- “The default random number generator has changed, so all random numbers will be different (even with the same seed) unless an explicit RNG object is used.” While people shouldn’t be relying on the exact numbers, it seems if might be confusing for some users to get a different stream for current and LTS. I’m not sure this affects package authors much, more what people read into the LTS term.
- Additional functions can be handled with Compat.jl, but I’m not sure it can handle new syntax, and 1.7 has an interesting “New language features” section, e.g. “Repeated semicolons” feature, and “backslash (
\) before a newline”. It seems annoying to be restricted to older syntax. - “
macroexpand,@macroexpand, and@macroexpand1no longer wrap errors in aLoadError. To reduce breakage,@test_throwshas been modified so that many affected tests will still pass (#38379).” That’s the first time I see “break[age]” ever in NEWS. I don’t make my own macros, and not up-to-speed on that feature, but I see it’s implemented with e.g. C code, so again I’m not sure Compat.jl can support it. - “Use Libblastrampoline to pick a BLAS and LAPACK at runtime.” A very important feature going forward, would it be bad to not have in LTS? Or was this it the other way?
I could go through all of NEWS, and I guess everything counts as a pro, Julia is continually improving. So what are the potential cons for 1.7? Anything obvious to see (there)?
- “The
RepStringtype has been moved to the LegacyStrings.jl package.” This isn’t a big deal as few using, but it seems strange to support it in LTS, if 1.6 chosen, but not in 1.7+. - The middle dot
·(\cdotpU+00b7) and the Greek interpunct·(U+0387) are now treated as equivalent to the dot operator⋅(\cdotU+22c5) (#25157). - The minus sign
−(\minusU+2212) is now treated as equivalent to the hyphen-minus sign-(U+002d) (#40948).
I’m not sure that new syntax will be hugely popular, but I would hate to be staring at code that looks identical (for dot, or very similar for minus), working in current Julia, and be confused why not working the same in 1.6 LTS. Maybe the error messages will be helpful and make obvious, but still I think bad for at least newbies.
Yes, I also hope 1.7 will support, as this seems like a very important package, and as far as I know the only package no longer supported by current Julia, nor LTS (i.e. 1.0.x), only supported by 1.3. I’m not up-to-peed on what broke it in 1.4, but if it can be fixed in 1.7, but not 1.6, then that’s an excellent reason for 1.7 to be LTS.
Some minor:
“Technically breaking”
You see that term occasionally, while never in NEWS. That’s not something to worry about for 1.7, but does it mean we wouldn’t want to backport to 1.6?
What I know of not mentioned in NEWS, lots of speedup in floating-point code (e.g. 50%), thanks to Oscar, and such aren’t mentioned as a constant factor. But there’s also fix for quadratic behavior regarding to memory allocations. It’s not mentioned in NEWS, I think because it’s a rare edge case. But I would want to avoid those in LTS too.
If we choose 1.7 and regret it, we could always add 1.6 as LTS (doubling backport effort), but if 1.6 is chosen then we can’t simply chose 1.7 and drop 1.6 as LTS, then it would be a short-term support version… However, the length/meaning of LTS has never been defined.
If 1.6 is chosen as LTS, what can we backport, or more importantly what CAN’t we backport from 1.7+? Anything obvious, good-to-have, feature?