# New Julia LTS? Are many using the current (Julia 1.6) LTS?

**URL:** <https://discourse.julialang.org/t/new-julia-lts-are-many-using-the-current-julia-1-6-lts/93919>\
**Category:** General Usage\
**Created:** [February 2, 2023, 12:04pm UTC](https://discourse.julialang.org/t/new-julia-lts-are-many-using-the-current-julia-1-6-lts/93919 "2023-02-02T12:04:03Z")\
**Posts on this page:** 20\
**Page:** 3

<div class="post-metadata">

**Author:** ![foobar\_lv2](https://avatars.discourse-cdn.com/v4/letter/f/ee59a6/32.png) [@foobar\_lv2](https://discourse.julialang.org/u/foobar_lv2)\
**Post date:** [January 17, 2024, 3:25pm UTC](https://discourse.julialang.org/t/new-julia-lts-are-many-using-the-current-julia-1-6-lts/93919/41 "2024-01-17T15:25:31Z")

</div>

> [@Tamas\_Papp](#):
>
> 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.

Sure, but that same argument of yours says “LTS is irrelevant in the first place”.

To give an example: At my day-job we need to schedule what java version we use for what projects. For various reasons, changing that is always an annoyance and needs some validation time (and sometimes it also needs adjustments, validation is not just for fun). So it is nice to be able to plan all that beforehand!  
And we actually have actually run into JVM bugs and needed an emergency patch, which we could yolo-deploy without large validation delays. Being on an LTS inside the support window guaranteed that such a patch would be forthcoming (in reality the patch came before LTS became relevant, so I’d classify that as a near-miss).

There is always an LTS we can pick that will be supported for a reasonable timeframe. This is a guarantee that is only possible with overlapping LTS support timeframes.

I’m not sure that the whole LTS effort is worth the amount of labor, for julialang specifically.

But if it is worth doing at all, then I think it is worth having overlapping support windows for graceful roll-over.

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [January 17, 2024, 3:38pm UTC](https://discourse.julialang.org/t/new-julia-lts-are-many-using-the-current-julia-1-6-lts/93919/42 "2024-01-17T15:38:01Z")

</div>

This is very clear:

- Introducing a new keyword to the language is definitively 100% no-doubt-about-it a new feature.
- Features are not backported. This isn’t just because that’s what SemVer says, but it’s also because net new code can and does have more bugs than battle-tested code… and it’s also a very meaningful simplification in how to understand a given release and its supported featureset.

Sometimes the line between bugfix and feature is indeed blurry, but this is not one of those times.

---

<div class="post-metadata">

**Author:** ![cjdoris](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cjdoris/32/213133_2.png) [@cjdoris](https://discourse.julialang.org/u/cjdoris)\
**Post date:** [January 17, 2024, 3:44pm UTC](https://discourse.julialang.org/t/new-julia-lts-are-many-using-the-current-julia-1-6-lts/93919/43 "2024-01-17T15:44:27Z")

</div>

> [@Palli](#):
>
> I just disagree with that anything that’s documented is API

Just to clarify, when I said documented, I mean documented in the official online documentation (at [docs.julialang.org](http://docs.julialang.org)), and NOT that there is a docstring. Indeed, a docstring can document non-API functionality. But if something is in the official docs, then it’s API unless stated otherwise. Same goes for packages.

---

<div class="post-metadata">

**Author:** ![xiaoxi](https://avatars.discourse-cdn.com/v4/letter/x/a9adbd/32.png) [@xiaoxi](https://discourse.julialang.org/u/xiaoxi)\
**Post date:** [January 17, 2024, 3:59pm UTC](https://discourse.julialang.org/t/new-julia-lts-are-many-using-the-current-julia-1-6-lts/93919/44 "2024-01-17T15:59:54Z")

</div>

Given that there is some leeway in choosing which version of Julia is LTS, one criterion for choosing which version is LTS might be which version contains features that can potentially change the way developers interact with Julia.

Is Julia 1.11 expected to contain any new features that could potentially change the way developers interact with Julia?

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [January 17, 2024, 4:14pm UTC](https://discourse.julialang.org/t/new-julia-lts-are-many-using-the-current-julia-1-6-lts/93919/45 "2024-01-17T16:14:22Z")

</div>

> [@foobar\_lv2](#):
>
> There is always an LTS we can pick that will be supported for a reasonable timeframe. This is a guarantee that is only possible with overlapping LTS support timeframes.
> 
> I’m not sure that the whole LTS effort is worth the amount of labor, for julialang specifically.
> 
> But if it is worth doing at all, then I think it is worth having overlapping support windows for graceful roll-over.

It’s worth being explicit about what the S in LTS means — the word “Support” is pretty laden with many meanings. In this case it’s quite limited and concrete: it means that there’s a branch onto which backports can land and from which a new patch release might be cut. That’s _also_ exactly the support that the most recent release gets.

So perhaps that is a reason to more officially signal the next-LTS before its official designation. For example, with the 1.6 release, it was informally signaled in discussions here as the next-LTS before it was officially named when 1.7 was released. On the other hand, it _is_ helpful to get a sense of a given minor release’s stability before designating it as the LTS, which is why it’s been pragmatic to wait on naming the LTS.

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [January 17, 2024, 4:31pm UTC](https://discourse.julialang.org/t/new-julia-lts-are-many-using-the-current-julia-1-6-lts/93919/46 "2024-01-17T16:31:12Z")

</div>

Barring bad (thus far unseen) problems with the release, Julia 1.10 is very likely to become the new LTS once we’ve gotten a couple of point releases out for it. So far there’s a bit of a kerfuffle about artifact hash mismatches making 1.10.0 unusable for Windows users not using Developer Mode, but that’s a very solvable problem that’s being addressed. Aside from that, the feedback about 1.10 has been quite positive, so it’s looking good so far.

---

<div class="post-metadata">

**Author:** ![foobar\_lv2](https://avatars.discourse-cdn.com/v4/letter/f/ee59a6/32.png) [@foobar\_lv2](https://discourse.julialang.org/u/foobar_lv2)\
**Post date:** [January 17, 2024, 4:58pm UTC](https://discourse.julialang.org/t/new-julia-lts-are-many-using-the-current-julia-1-6-lts/93919/47 "2024-01-17T16:58:24Z")

</div>

> [@mbauman](#):
>
> it means that there’s a branch onto which backports can land and from which a new patch release might be cut. That’s _also_ exactly the support that the most recent release gets.

Sure, but it also means: If a bad bug is discovered, then there will be another release. If people report bad bugs for most recent patch-release of LTS, then they won’t be closed on github because “incidentally fixed on latest release / master”.

“bad bug” means something that is hard to workaround. E.g. a crash due to llvm-bugs. Or in the jvm world, [Loading...](https://bugs.openjdk.org/browse/JDK-8208275) where the workaround (barring the patch) was “disable C2 via command line option or pray that you don’t trigger the faulty optimizer path” (with the obvious performance impact).

---

<div class="post-metadata">

**Author:** ![tbeason](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tbeason/32/15898_2.png) [@tbeason](https://discourse.julialang.org/u/tbeason)\
**Post date:** [January 17, 2024, 4:59pm UTC](https://discourse.julialang.org/t/new-julia-lts-are-many-using-the-current-julia-1-6-lts/93919/48 "2024-01-17T16:59:49Z")

</div>

Are there statistics out there to try to tease out how often used LTS is versus other releases? Like do the package download stats provide the Julia version which is used to install the package?

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [January 17, 2024, 6:13pm UTC](https://discourse.julialang.org/t/new-julia-lts-are-many-using-the-current-julia-1-6-lts/93919/49 "2024-01-17T18:13:11Z")

</div>

Yes, it does. Here’s the super-naive thing of just the total number of requests over the past 365 days and since Jan 1

> **code**
>
> ```Julia-repl
> julia> using CSV, DataFrames, StatsPlots, Dates
> 
> julia> download("https://julialang-logs.s3.amazonaws.com/public_outputs/current/julia_versions_by_date.csv.gz", "julia_versions_by_date.csv.gz")
> "julia_versions_by_date.csv.gz"
> 
> shell> gunzip julia_versions_by_date.csv.gz
> 
> julia> using CSV, DataFrames
> 
> julia> df = CSV.read("julia_versions_by_date.csv", DataFrame);
> 
> julia> round2(v::VersionNumber) = VersionNumber(v.major, v.minor);
> 
> julia> round2(s::String) = round2(VersionNumber(s));
> 
> julia> df.ver = passmissing(round2).(df.julia_version_prefix);
> 
> julia> year = combine(groupby(df, [:ver, :client_type]), :request_count=>sum)
> 19×3 DataFrame
> Row │ ver client_type request_count_sum
> │ VersionN…? String7? Int64
> ─────┼────────────────────────────────────────────
> 1 │ 1.10.0 ci 53358405
> 2 │ 1.10.0 user 5730295
> 3 │ 1.11.0 ci 37586328
> 4 │ 1.11.0 user 413803
> 5 │ 1.4.0 user 220
> 6 │ 1.5.0 ci 4910894
> 7 │ 1.5.0 user 4021822
> 8 │ 1.6.0 ci 69154035
> 9 │ 1.6.0 user 14530981
> 10 │ 1.7.0 ci 32761499
> 11 │ 1.7.0 user 10527367
> 12 │ 1.8.0 ci 195937632
> 13 │ 1.8.0 user 66641408
> 14 │ 1.8.0 missing 14
> 15 │ 1.9.0 ci 263533819
> 16 │ 1.9.0 user 81199727
> 17 │ 1.9.0 missing 3
> 18 │ missing user 1755
> 19 │ missing missing 21240148
> 
> julia> Base.string(v::VersionNumber) = "$(v.major).$(v.minor).*" # 🙈
> 
> julia> groupedbar(year.ver, year.request_count_sum, group=year.client_type)
> 
> julia> title!("past 365 days")
> 
> julia> jan = combine(groupby(df[df.date .>= Date(2024), :], [:ver, :client_type]), :request_count=>sum)
> 17×3 DataFrame
> Row │ ver client_type request_count_sum
> │ VersionN…? String7? Int64
> ─────┼────────────────────────────────────────────
> 1 │ 1.10.0 ci 13527933
> 2 │ 1.10.0 user 3101779
> 3 │ 1.11.0 ci 4158854
> 4 │ 1.11.0 user 50850
> 5 │ 1.4.0 user 9
> 6 │ 1.5.0 ci 144184
> 7 │ 1.5.0 user 28700
> 8 │ 1.6.0 ci 2189234
> 9 │ 1.6.0 user 294051
> 10 │ 1.7.0 ci 981152
> 11 │ 1.7.0 user 182143
> 12 │ 1.8.0 ci 1643867
> 13 │ 1.8.0 user 784637
> 14 │ 1.9.0 ci 14774967
> 15 │ 1.9.0 user 3614720
> 16 │ missing user 72
> 17 │ missing missing 3636205
> 
> julia> groupedbar(jan.ver, jan.request_count_sum, group=jan.client_type)
> 
> julia> title!("in 2024")
> 
> ```

 ![image](https://global.discourse-cdn.com/julialang/original/3X/e/2/e200c63e9acdd401929a02ea5f69526455bac3fb.png)

 ![image](https://global.discourse-cdn.com/julialang/original/3X/5/9/59b75947c962dc64712449733bcf55e4f153feeb.png)

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [January 18, 2024, 9:31am UTC](https://discourse.julialang.org/t/new-julia-lts-are-many-using-the-current-julia-1-6-lts/93919/50 "2024-01-18T09:31:36Z")

</div>

> [@foobar\_lv2](#):
>
> Being on an LTS inside the support window guaranteed that such a patch would be forthcoming (in reality the patch came before LTS became relevant, so I’d classify that as a near-miss).

AFAIK there are no such explicit guarantees for Julia. What you get with Julia LTS is the _possibility_ that the branch will get _some_ backports (as opposed to all previous versions), but no timeframe.

I think it is important to address the concerns of LTS users, but then it would be good to hear from them directly instead of speculating. I am wondering what fraction of participants in this discussion (or any of the other “is 1.x the new LTS?”) actually use an LTS.

@foobar_lv2, @Palli, do you actually use 1.6 as your main Julia version?

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [January 18, 2024, 11:10am UTC](https://discourse.julialang.org/t/new-julia-lts-are-many-using-the-current-julia-1-6-lts/93919/51 "2024-01-18T11:10:49Z")

</div>

I no longer use 1.6, I always use latest stable, and/or master.

My point is that package developers should disregard 1.6, but also make packages for 1.11 which means disregarding ~~1.11~~ 1.10. 1.10 without “public” shouldn’t hold back good software development, or make it any more difficult to support 1.10 as it.

What’s the point of LTS? It’s backwards-looking, I can use packages already developed, but also to some degree forward-looking, I can expect (security) updates for some (unspecified) “long time” (for Julia, maybe also packages), at least more than a year, or not just until next stable release.

If I were considering an LTS for say the next two years (e.g. developing my own software), then I might want to use latest packages developed in say the next year. Then the package ecosystem has a problem.

> [@StefanKarpinski](#):
>
> Julia 1.10 is very likely to become the new LTS once we’ve gotten a couple of point releases out for it.

That will certainly be more helpful than 1.6, but without “public” it seems we might as well declare 1.9 LTS and drop 1.6.

---

<div class="post-metadata">

**Author:** ![goerz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/goerz/32/3269_2.png) [@goerz](https://discourse.julialang.org/u/goerz)\
**Post date:** [January 18, 2024, 12:11pm UTC](https://discourse.julialang.org/t/new-julia-lts-are-many-using-the-current-julia-1-6-lts/93919/52 "2024-01-18T12:11:07Z")

</div>

Someone could probably implement a macro `@public` that does the same as `@compat public` but is slightly prettier, no?

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [January 18, 2024, 1:50pm UTC](https://discourse.julialang.org/t/new-julia-lts-are-many-using-the-current-julia-1-6-lts/93919/53 "2024-01-18T13:50:40Z")

</div>

> [@Palli](#):
>
> also make packages for 1.11 which means disregarding 1.11

Sorry, my mastery of Zen Buddhism is not sufficient to understand this koan.

> [@Palli](#):
>
> What’s the point of LTS?

> **[Julia’s Release Process](https://julialang.org/blog/2019/08/release-process/#long_term_support)**
>
> Julia’s Release Process | People involved in the day-to-day development of a project tend to become so familiar with its rhythm and process that they internalize it and it feels like everyone must just \_know\_ how each stage unfolds. Of course, from...

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [January 18, 2024, 3:03pm UTC](https://discourse.julialang.org/t/new-julia-lts-are-many-using-the-current-julia-1-6-lts/93919/54 "2024-01-18T15:03:56Z")

</div>

I had a typo (now fixed), I meant “make packages for 1.11 which means disregarding **1.10** ”, meaning good packages for 1.11 use public (where applying) and by doing such disregard 1.10 users by default, or make work for themselves to support older releases too, that would be avoided if LTS has support for public.

Do you think “public” will actually not be used much in packages as opposed to Julia itself (since there it’s problematic to export)?

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [January 18, 2024, 3:35pm UTC](https://discourse.julialang.org/t/new-julia-lts-are-many-using-the-current-julia-1-6-lts/93919/55 "2024-01-18T15:35:42Z")

</div>

There are _always_ new goodies that folks will want from newer releases (see, e.g., [v1.7](https://discourse.julialang.org/t/what-are-the-current-plans-regarding-a-new-lts-julia-version/63501)). That’s a good thing. That’s something you explicitly sacrifice in choosing to use any LTS of any software.

Yes, many packages choose to use Julia’s LTS marker to drive their own development practices. But that’s also why Compat.jl exists.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [January 18, 2024, 3:37pm UTC](https://discourse.julialang.org/t/new-julia-lts-are-many-using-the-current-julia-1-6-lts/93919/56 "2024-01-18T15:37:42Z")

</div>

> [@Palli](#):
>
> good packages for 1.11 use public (where applying) and by doing such disregard 1.10 users by default

Generally if you _need_ a feature present from Julia 1.11, you will need to either lower bound the Julia version in compat or use `Compat.jl` if possible.

This does not “disregard” 1.10 users, because once 1.11 is released, they can (and should) just upgrade.

> [@Palli](#):
>
> Do you think “public” will actually not be used much in packages

I don’t think this is relevant to the present discussion. Every release introduces new features, which some packages end up using. That’s how software works — otherwise there would not be any point in making new releases. We have versioning and compat bounds to deal with this smoothly.

Also, this is pretty much irrelevant to the recurring “is 1.x the new LTS” discussions, of which you have started quite a few, for reasons I still don’t understand.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [January 18, 2024, 3:47pm UTC](https://discourse.julialang.org/t/new-julia-lts-are-many-using-the-current-julia-1-6-lts/93919/57 "2024-01-18T15:47:52Z")

</div>

Maybe I make to big of a deal out of this, currently less than 1.4% of packages ([Direct (132)](https://juliahub.com/ui/Packages/General/Compat/#) [Indirect (4640)](https://juliahub.com/ui/Packages/General/Compat/#) users) have Compat.jl as a direct dependency, and from now on, close/r to a 100% might need to, annoying to add and I’m not sure how many even know of its existence, but now they need to, and add, or possibly tools can automate it?

All those that do not will make the LTS second class (a good reason to not use it from now on for new code; then an argument sort of to not release a new LTS…), more so than in the past. Usually the same syntax/keywords have worked on latest vs. LTS, and now that is broken. It feels worse than some obscure (e.g. LinearAlgebra) added function that few need.

> [@Tamas\_Papp](#):
>
> This does not “disregard” 1.10 users, because once 1.11 is released, they can (and should) just upgrade.

Right most can and should, and how does that not disregard 1.10 users? I.e. those that want to use 1.10 _LTS_? Current 1.6 LTS users can “disregard” the possible new LTS (1.10 likely), nobody is forcing users to opt into it.

It seems the new possible 1.10 LTS (assuming `public` not added) will be dead-on-arrival, with people not wanting to use it. It’s not in _users_ hands to add Compat to packages, except by bugging the package ecosystem developers to add it (or make a PR), or even worse a separate branch (that will get left behind).

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [January 18, 2024, 4:01pm UTC](https://discourse.julialang.org/t/new-julia-lts-are-many-using-the-current-julia-1-6-lts/93919/58 "2024-01-18T16:01:47Z")

</div>

> [@Palli](#):
>
> All those that do not will make the LTS second class

Apparently you don’t understand what LTS is for.

Just to clarify, if you are using Julia 1.x, _all_ packages that are currently working on it will continue working the same way forever. Some will get updates, and at some point some of these would require 1.y \> 1.x, then from that point on you will be missing updates. **That applies to all Julia versions, LTS or not.**

The only difference for LTS is that you get some backports. The users who stick to LTS are [low risk tolerance](https://julialang.org/blog/2019/08/release-process/#risk_tolerance_personas), meaning that they don’t upgrade their packages for no good reason either, so in all likelihood they lose nothing by missing updates. They update to the new LTS when it comes out, at which point they presumably update the packages, review package API changes, run their most extensive test suite, etc.

There is no way one can keep up with _all_ package updates and stick to an older Julia version, LTS or not, regardless of Compat. Some packages will make an extra effort to support the latest LTS, some won’t. This decision is up to the package devs.

> [@Palli](#):
>
> LTS users can “disregard” the possible new LTS (1.10 likely)

Sure they can, but in all likelihood they will want to update.

> [@Palli](#):
>
> the new possible 1.10 LTS (assuming `public` not added) will be dead-on-arrival, with people not wanting to use it

There were a lot of new features between 1.6 and 1.10 which I guess almost all LTS users may want to use at some point, but we shall see.

To be frank, **I still don’t get what you want from this discussion**. Make every release an LTS? (Because you opened a similar topic for almost all recent releases). Or make 1.11 the next LTS just because it has `public`?

---

<div class="post-metadata">

**Author:** ![tbeason](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tbeason/32/15898_2.png) [@tbeason](https://discourse.julialang.org/u/tbeason)\
**Post date:** [January 18, 2024, 4:13pm UTC](https://discourse.julialang.org/t/new-julia-lts-are-many-using-the-current-julia-1-6-lts/93919/59 "2024-01-18T16:13:32Z")

</div>

I also find it interesting that you are asking so much about the LTS when you said you do not use it. I live on the bleeding edge… once something hits RC or beta then I switch to that. I do not look back at or care about prior releases anymore.

Is your concern that supporting an LTS slows development of new language features? Is your concern that the LTS is inferior to the latest release, so that people who need that long-term stability will not choose Julia over something else?

---

<div class="post-metadata">

**Author:** ![joa-quim](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/joa-quim/32/227_2.png) [@joa-quim](https://discourse.julialang.org/u/joa-quim)\
**Post date:** [January 18, 2024, 4:14pm UTC](https://discourse.julialang.org/t/new-julia-lts-are-many-using-the-current-julia-1-6-lts/93919/60 "2024-01-18T16:14:17Z")

</div>

> [@Tamas\_Papp](#):
>
> Or make 1.11 the next LTS just because it has `public`?

This does not looks unreasonable to me. But on the other hand, I never really understood the value of the LTS _tags_ anyway.

[Previous page](https://discourse.julialang.org/t/new-julia-lts-are-many-using-the-current-julia-1-6-lts/93919.md?page=2)

[Next page](https://discourse.julialang.org/t/new-julia-lts-are-many-using-the-current-julia-1-6-lts/93919.md?page=4)