# Forward compatibility and stability of Julia vs. Packages

**URL:** <https://discourse.julialang.org/t/forward-compatibility-and-stability-of-julia-vs-packages/97968>\
**Category:** General Usage\
**Created:** [April 25, 2023, 6:09pm UTC](https://discourse.julialang.org/t/forward-compatibility-and-stability-of-julia-vs-packages/97968 "2023-04-25T18:09:37Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![aplavin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aplavin/32/222056_2.png) [@aplavin](https://discourse.julialang.org/u/aplavin)\
**Post date:** [April 26, 2023, 7:29pm UTC](https://discourse.julialang.org/t/forward-compatibility-and-stability-of-julia-vs-packages/97968/6 "2023-04-26T19:29:21Z")

</div>

> [@tim.holy](#):
>
> Examples?

Among recent breakages that I remember - 1.9 broke SortAlgorithms, and versions before the corresponding fix don’t even precompile. So, lots of packages effectively broken by 1.9, because SortAlgorithms is a very popular dependency (eg through StatsBase).

Sure, it happens because they used some internals not covered by semver. But for the user this doesn’t change anything.

Would be interesting to test this systematically from time to time. Run tests of all packages with Julia 1.x, fixing the registry state to the release date of Julia 1.(x-1).0.

> [@New Julia LTS? Are many using the current (Julia 1.6) LTS?](https://discourse.julialang.org/t/new-julia-lts-are-many-using-the-current-julia-1-6-lts/93919/14):
>
> Julia `1.x` to `1.(x+1)` will almost always be safer than upgrading a package `x.y.z` to `x.y.(z+1)`

IME, updating a package this way almost never breaks anything. It helps that packages typically have much fewer dependents than Julia itself (everything depends on it).

---

_[View the full topic](https://discourse.julialang.org/t/forward-compatibility-and-stability-of-julia-vs-packages/97968)._