Would slowing Julia's release cadence improve ecosystem quality?

[Palli]

@xiaoxi

Could it help improve the quality of the Julia ecosystem if Julia releases slow down their pace after the next LTS release

I don’t think so. And I would want to go the other way, have more frequent releases.

I don’t see much of an ecosystem quality problem, relating to new Julia versions (I think others agree here, except for a minor update problem, and I proposed how to fix that):

Forward compatibility and stability of Julia vs. Packages

You brought up at (I didn’t want to answer there/derail the main topic?): It could be argued those packages would depend on 1.x+1 but that wouldn’t solve the problem, because then yes those versions would no longer be installable in that Julia, and would force use of older versions of the packages, that also wouldn’t work. So it got me thinking, should it be the other way around, Julia having [compat] on some packages? I’m just not aware that Julia has a Package.toml file per se (at least not…

I obviously don’t control the frequency of releases, but if each one is trying to be a smaller upgrade (maybe not trying to be very small) then they can be more frequent, and less of a worry to miss the feature freeze. People might argue it’s too much work, but we have up to 6 point releases, and with more 1.x releases, I think we need fewer if any 1.x.y, so less backporting work.

[Julia is the first language I’m involved with contributing to. I’m not sure, does Julia have more regressions than others? I have no way to back that up, could actually be fewer. Do people think too many/more than expected? And I’m thinking of genuine ones, fixes (or needing) in point releases, not talking about stuff an upgrade of packages fixes.]