I think it’s worth taking a step back and noting that there are four different flavors of compatibility being discussed in this thread.
- Holding packages constant and changing Julia versions forwards (Julia’s forwards compatibility)
- This is where we started — and what @aplavin wants to have work, with that concrete case of SortingAlgorithms removing its prior dependency on internals. And this is where @CameronBieganek would put upper bounds to prevent the use of some old packages on newer Julias by rule. This is where we have PkgEval to help test new Julia releases and ensure the package ecosystem works with the new Julia version (yes, potentially by requiring new package versions).
- Holding packages constant and changing Julia versions backwards (Julia’s backwards compatibility)
- This isn’t guaranteed — indeed packages may always choose to bound Julia versions so they can depend upon newer Julia features. Many package authors choose to support the most recent LTS+, but the desire to continue to support very old Julia versions was expressed in the original LTS thread before I split it by @stemann in New Julia LTS? Are many using the current (Julia 1.6) LTS? - #10 by stemann.
- Holding one package constant and changing another package forwards
- These are the typical semver upper bounds that get put in
[compat]— and these are indeed becoming more common thanks to CompatHelper.jl and this is the most common case in which it bumps things up. It’s much much less common for packages to do the equivalent of Julia’s PkgEval when releasing new versions, and this is where @Elrod is saying it can be more dicey than that first bullet.
- These are the typical semver upper bounds that get put in
- Holding one package constant and changing another package backwards
- This is the case that @ChrisRackauckas describes with old Trebuchets and pinned DataFrames ecosystem. Just as with Julia’s backwards compatibility it’s not guaranteed to work by the terms of semver but unlike Julia folks are much less likely to think about the package versions that introduce new features and bound them because it’s not often tested. And it’s much harder to test (typically folks have a matrix of Julia versions in CI, this would require a matrix of package dependency versions). CompatHelper will help you get started here, but it won’t identify that some new code relied upon newer dependency than you started with.