Julia 1.6 was released on 24 March 2021, but wasn’t declared LTS until Dec 2021 (previous LTS, 1.0, was LTS for just over 3 years). Should we go for 18 month LTS support as node.js?
There has never been a promise for how long long-term support means for Julia (and I’m not even sure how desirable an LTS is, with juliaup now supported on all platforms), and 1.6 is a non-ideal LTS version (has known bugs that are not fixed, or at least one, likely rather obscure though), and incompatible syntax with newer versions (and a different RNG).
So I want to get rid of Julia 1.6 as LTS sooner rather than later. We could have a new LTS, even for some time concurrently, would 1.8 be a good candidate?
LTS means, down to 6 months for some projects, up to 10+ years, or 18 months for the only language (JavaScript, i.e. node.js) there in that projects list: Long-term support - Wikipedia
Should we emulate their schedule (maybe also for new releases every six months?):
New semver-major releases of Node.js are branched from main every six months. […]
Every even (LTS) major version will be actively maintained for 12 months from the date it enters LTS coverage. Following those 12 months of active support, the major version will transition into “maintenance” mode for 18 months.
If you are not sure how desirable an LTS is, I would assume you don’t need it personally, so I’m not clear on your motivations to “get rid of Julia 1.6 as LTS sooner rather than later”… maybe people using LTS prefer longer terms LTS versions, even if the current one as some problems?
Two concurrent LTS versions will probably not happen, as it’s more work.
I would be ok with 1.8 being declared immediately just to get 1.6 dropped as LTS (I don’t use LTS and even use master), but I’m fishing if people think it’s too soon, or if there’s actually much interest in LTS at all. Of course it’s more work to have two (or more, not suggesting that) LTS, so I was thinking at best a short overlap, depending on for how long people want the LTS supported, which hasn’t been discussed as far as I know.
I’m not sure what the SciML policy is, but personally, I’m ready to stop adding new features to all but the latest release whenever.
If someone really wants LTS julia, they’re unlikely to want to be on the latest package versions.
Almost all breakages and regressions I see are from the package ecosystem, not new Kulia releases.
So finding new Julia releases too onerous but keeping up with the package ecosystem acceptable would be an odd preference.
Julia 1.0 was the LTS for 3 years. Julia 1.6 has been the LTS for barely over 1 year. I think it’s a little premature to be calling it dead; 1.6 was a fantastic release and is still going strong.
Keeping the LTS status for 3+ years yields a strong argument in favor of Julia when discussing (random) alternatives, e.g. it matches the .NET release cadence: .NET and .NET Core official support policy
I wouldn’t even complain if the two latest LTS versions were supported, e.g. LTS versions released every 3 years with 6 years of support each.
No, 3 years of support for 1.6 doesn’t really help, if it means to 24 March 2024, then less than one year, less than the 1 year to be expected for 1.9. For those adopting Julia LTS NOW, for some project, it’s very unlikely 1.6 will be supported for three more years, from now on. And what matters to users, is some long-term commitment, so I would argue for a new LTS, e.g. 1.9, that’s about to be released, as the LTS commitment is a forward-looking statement. I think we might want to keep 1.6 LTS, for a little overlap, e.g. 3-6 months the most, at least do not announce it no longer supported and give no warning, as happened last time around. And during the overlap it could be for security support only.
While Julia 1.0 was an exception, the policy going forward (if I understand correctly) is that the LTS is declared only after the next release is out: 1.6 became LTS only when 1.7 was released. Paraphrasing/mangling something that I believe @StefanKarpinski has said, you only know how the cake turns out once you’ve had a chance to taste it for a bit. Remember that we have to support the LTS with patches, backports, etc., and that means making sure it doesn’t cause so many problems that this support becomes a major headache. Every new LTS is a significant drain on at least one person’s resources, with minor costs to a larger pool.
If we’re not declaring 1.9 the LTS now, what’s the other best candidate? Answer: 1.6. With such exciting changes coming in 1.9, it doesn’t make any sense to declare 1.8 an LTS. 1.9 may well become a new LTS, but we won’t know that until 1.10 is entering final stages of development. I’d say this discussion is a bit premature.
Is it entering final stages? I see: “Set VERSION to 1.10.0-DEV (#47222) 6 months ago”
I agree 1.8 doesn’t make sense as LTS, it should be 1.9 (or even 1.10?). I believe 1.9 took longer to get done than expected. Will 1.10 hit feature freeze any day now? Are there interesting features there you would want in an LTS, or even interesting features that people want to wait for before a feature freeze (that are almost there) for 1.10, independent of it becoming a potential LTS?
Not sure whether they are things that would delay a release, but two potentially important features of 1.10 I’ve heard people talking about are work on load time (which I think has already borne fruit on master) and the integration of JuliaSyntax into base.
Those new features need not be in 1.10, or at least delay it, nor are needed for LTS. JuliaSyntax.jl will be merged, but off by default. I guess that way ok for LTS even, but when turned on (by default), it will be rather new (even has bugs now), so wouldn’t fit for LTS. Probably 1.9 will be the next LTS, but I would still intependently of that want to know how soon 1.10 could be ready. According to Wikipedia Julia is on a time-based schedule now (since 1.7), and smaller more frequent releases have been discussed.
