I would make a small distinction between “end-user packages” and “developer packages”. The latter would be primarily used as dependencies for end-user packages, or as tooling for testing and documentation. It probably wouldn’t be a terrible idea for “developer packages” to be compatible with all “active” versions of Julia (which presumably is up to the last LTS). This is because dropping support for a Julia version in a developer package pushes all dependents to drop support for that Julia version as well (or else forgo bug fixes in their dependencies), which might be a bit disruptive. The more restrictive packages with many dependents are in their own dependencies (Julia or otherwise), the more potential there is for ending up with unresolvable constraints for a larger downstream project.
I’d be inclined to think PrettyTables is more in the category of developer packages. But maybe look at the number of dependents. Of course, I can’t exactly make demands on any particular maintainer: if it’s too much of a burden, do what you have to do
For “end-user package”, i.e., packages that don’t have many dependents and are typically targeted at just solving some particular computational problem, by all means: support only the latest Julia version, or whatever is most convenient. I’m certainly considering dropping support for Julia <1.9 myself to make use of package extensions without the overhead of making that backwards compatible.
If you are using the LTS your expectation should generally be that you’re not going to get anything new. No new language features, bug fixes only. Package versions that used to work continue to work will continue to work, but you may or may not get any new versions. You may need to fix packages yourself if there are critical issues and you need to keep using them. I’ve said many times that very few people should be on LTS and I kind of agree that it almost shouldn’t exist. If you don’t like it, please ignore it!
As someone who uses the LTS version of Julia, I can speak to both, my expectations as well as my reasons.
Expectations: I expect security patches to be applied to the LTS release of Julia. I do not expect new features or non security related bug fixes.
I pin packages in my manifest and periodically (3 times a year) will look at new versions and upgrade if sufficiently stable. There have been cases where we’ve decided not to upgrade certain packages due to small algorithm changes even though we agree with those changes because it would cause disruptive changes in analysis results for our customers.
Reasons: we provide our customers with a Jupyter interface to our data. These customers typically write code once and rarely want to touch it again. When we make changes, we need to guarantee that the code they’ve written, and that we’ve never seen, will continue to work (or we lose money). There only way I can guarantee that is by keeping versions stable.
While it may be true that things don’t break across Julia 1.x versions, I’m the one that needs to test to make sure that holds.
Fwiw, we do the same with Python and Python packages.
