Oh, cool! Thanks.
@viralbshah Is that still on the table and then 1.9 as LTS? Since Statistics hasn’t yet been made a stdlib, and you continue with:
Hopefully we have conditional dependencies in place by then, and can even move out SparseArrays and perhaps a few other things as well for the new LTS.
JuliaSyntax.jl has been merged into 1.10, which is now alpha1. It would be nice if it were used in LTS, since it has faster parsing, and better error messages, but I suppose it could be backported to 1.9 at some point, since it’s supposed to be a non-breaking change, if 1.9 would become an LTS?
1 Like
The current “plan” is to make 1.10 the LTS. 1.9 had a ton of features added at (after) the very end of the release cycle, so although it’s really nice, there is some concern about it’s long term stability.
14 Likes
Does anyone have information about the release date for the new LTS, or should we assume that Julia 1.6 will continue to be the LTS for an extended period?
See the release process: Julia’s Release Process
The LTS is not a release, it’s a label that signals support for critical backports. And it’s a label that’s retroactively applied to an existing release after a new release is released. For example, v1.6 officially became the new LTS eight months after its release — when v1.7 was released.
For the vast vast majority of people, you shouldn’t worry about using the LTS. The latest release is just as supported and stable (if not more so) — and it’s far easier to incrementally update single minor versions at a time than jumping from LTS to LTS.
4 Likes
You really should not use 1.6 “LTS” by now. A new release 1.6.8 has been planned since July 20, 2022 and you can see that it has lots of backports, that have accumulated over time. Last activity I noticed from 2 months ago was to upgrade to LibCURL.v7.73.0+4 from LibCURL.v7.73.0+3.
Since then there’s been no activity until I commented on Dec. 4:
Is the libcurl CVE serious? libcurl is not just for Pkg, also Downloads?
I.e. should this just be released, as possibly, the last 1.6 LTS?
I don’t care personally about the LTS, any version, I just want that one to go away. It seems abandoned/forgotten with “4 successful, 3 failing, and 4 pending checks”. It feels like false sense of security thinking another 1.6 LTS will be released.
I think people are putting off publishing a new LTS minor version.
Maybe we will actually get that 1.6.8 version, maybe nobody is pushing for it, but note there are additionally 5 issues labelled with “backport 1.6” the oldest a bugfix from 2021:
https://github.com/JuliaLang/julia/pulls?q=is%3Aopen+is%3Apr+label%3A"backport+1.6"
We recently upgraded to 8.4.0, and since then 8.5.0 is out:
Not for “extended period” (from now on).
I think we should just discontinue the LTS, even with no replacement (right away), given the semi-official from @viralbshah :
Realistically, we are unlikely to make new 1.6 releases now - so perhaps we should close.
That’s fine by me. Does that mean 1.10 will be the next LTS, or am I misinterpreting things?
I believe that decision cannot be taken until 1.10 is out and we are closer to 1.11. Please don’t treat either of my statements as official. Just observations on my part.
[Are we close/r to 1.11 now?]
I just think it’s more honest, for new users, do not give them a false sense of security. We could simply drop the LTS from the Downloads page, or keep it there, and state NOT recommended [for new installations] in bold.
What are “critical” updates? E.g. critical security updates, and I do see unpatched CVEs for the LTS, I’m not sure how “critical” they are. Then there are simply bugs, critical or not, not sure, e.g. recent (from the month before Viral’s comment):
Possibly at least one more release, with (just?) the (already accumulated) LTS backports, though I’m not at all pushing for that.
Could we make a statement that 1.10, e.g. from 1.10.1 will likely become LTS? At least try to get the users to adopt it, and the ecosystem, and for it do not feel a need to support 1.6? Only support 1.10, or maybe 1.9 (is 1.9 officially unsupported now?).
Will the new “public” keyword be backported to 1.10?
1 Like
No, usually features are not backported, only bugfixes
3 Likes
I’m confused, public is for any API, not just Julia’s, so you really want to declare it in packages?! I.e. 1.6, and even 1.10 is holding Julia’s ecosystem back. And it seems trivial to backport, just support it in the parser? Even as a no-op. I think full support may do more, but I meant (even just) support parsing it.
Does this mean only 1.11 could become the new LTS? Or you’re wrong and it could be backported before 1.10 made LTS?
Packages may have multiple branches, with the latest branch only supporting v1.11+ and declaring the public symbols, whereas the other branches may support versions up to v1.6 (or possibly lower). This does not require any LTS to be declared.
4 Likes
You can use Compat.jl if you want to use public on earlier versions of Julia: GitHub - JuliaLang/Compat.jl: Compatibility across Julia versions
2 Likes
Yes, you can use Compat (I actually knew that), while annoying, not all would know, and even more annoying to use a branch. Both “solutions” would mean all packages would need to to this, and all their dependencies (or not use public).
Yes, it’s possible, or just add support for “public” keyword. Doesn’t seem hard. If thought of as breaking, then add to 1.10.x when 1.11 is released and 1.10 would have been made unsupported anyway…
Julia doesn’t backport features. Doing so is incompatible with semver. Say it was ported to 1.9.9, then 1.10.0, which doesn’t have the feature, would not be compatible with 1.9.9.
3 Likes
It wouldn’t actually break semver to backport to 1.10 (or whatever is latest stable). To 1.9 maybe if not also (first) to all later versions.
Semver is about same API, and only problem is dropping something from the API, or changed meaning (semantically same as dropping and adding with new meaning).
[Maybe arguably it would take away publis as a usable variable, though I’m not even sure there would be a conflict.]
Yes, it would. Semantic versioning doesn’t distinguish between backporting something or adding it from scratch and adding a new feature requires a minor version bump.
2 Likes
I don’t think feature backports that turn errors into something else are too problematic. But backports of some optimizations could be very problematic. E.g. some more tbaa / aliasing metadata are added; some code happens to be well-tested and work against julia 1.x.y, but is formally UB; and version 1.x.(y+1) causes compiler optimizations that make this code not work as intended anymore.
Regarding LTS in general, my viewpoint is the following: For some projects, I want to choose a version that (1) is “well hung”, i.e. has most visible bugs already fixed, and (2) will be supported (ie receive critical bug-fixes) for as long as possible.
A really good example is this table.
Given that goal, I fear that “only one LTS version supported at the same time” is fundamentally insufficient:
The goal is that at every time t, there exists an LTS version that can be used now, and that will be supported for N months in the future.
If there only exists a single LTS version at all times, then there is no overlap in support windows, and we cannot guarantee a single month of support for projects that choose their target version in the last days before switching LTS versions.
That’s the same issue as when you e.g. roll-over cryptographic keys: If there is any caching / asynchrony involved, then you must have an overlap of validity timeframes, and this overlap must at least be as long as the TTL (the TTL in our context is the number N of months of support that we want to guarantee for users who choose the newest LTS version at the worst possible moment).
1 Like
Is this a practical concern though? At the end of their life cycle LTS versions can expected to be pretty stable, in the sense that very few criticals bugs warrant backporting. Eg 1.6 got its last update 8 months ago, and then one two years before that.
I imagine that someone using an LTS has ample time to upgrade to the next one without any major problems. It’s not like your Julia executable will suddenly sprout new bugs just because it is no longer the LTS.
That said, I am surprised by the “is 1.x the new LTS” discussions anytime a new version is released. Are that many people using 1.6? What’s preventing them from upgrading that is not applicable once a new LTS is announced?
4 Likes
I might actually be wrong (and I always hate that) so I looked up:
- Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backward compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code.
Yes, so it depends on if “public” keyword, or any new “feature” is “backward compatible functionality is introduced to the public API”. Note:
- Patch version Z (x.y.Z | x > 0) MUST be incremented if only backward compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior.
The “public” keyword is arguably a fix, it’s to allow declaring API public, but the keyword itself (and enabling it) is it actually a feature? Is it added to any API?
If you try to run code that works in 1.11 (has the keyword) then you will get a parse error (which yes, is avoidable with e.g. Compat.jl, just a burden), so is it a “bug”? It sure prevents running the code, but Julia never promised new code working on old Julia, only forward compatibility. It seems rather innocent to add the keyword in a patch release. If you don’t use the keyword than the “functionality” in the parser will never be triggered, but if you try it would fail, so in some sense a “bug”…
[What could alternatively be done, is add the public keyword, at some point (when declared an LTS), and then upgrade to 1.11.0, with that only change. And rename master/1.11 to 1.12… Or wait until current master is released with public and postpone LTS until then, meaning likely closer to 1.13 release… seems very unideal.]
It may seem like language layering, but what is the point of the semver concept? It’s to prevent surprises (mostly dropped features). Any change (adding and) especially, removing/changing is a potential bug. You want to know with a new version number, and the major version is very meaningful.
Adding new features, or even just optimization of old ones may be badly implements introducing bugs. But parsing public is very low on the risk scale.
There’s plenty of precedent of “technically breaking” changes in Julia, and if you (would have wanted strict semver adherence, we would have had 2.0, 3.0 etc. already. “Public” is the least of my worries, adding it, but I worry a lot about not adding it. It prevents its use for years (if not added to LTS), or splits the ecosystem or burdens ALL package developers.
Yes it’s a new feature of the language. The code public foo has a documented (therefore API) effect on Julia 1.11, but is a syntax error on older versions.
2 Likes
The public keyword is a new feature yes, and of course its existence is documented, I just disagree with that anything that’s documented is API (explicitly its not, lots of internal functions in Julia are documented, and that does not promise it’s API, even though you can call stuff).
You can call foo if it’s exported (and actually also if not exported, a source of much discussion and grief for many, then e.g. Base.foo), and then it’s an API. Doing public foo, means that foo is now API (without needing exporting, it doesn’t change in any way what was possible before about foo), but the mechanism, to allow declaring foo pubic is not API, it’s a marker, or well to allow marking. I at least tend to think of functions/methods as API. E.g if there had been public() or declare_public(function_as_argument).