Versioning packages for breaking upgrades

Posted May 31, 2024 20:25 UTC (Fri) by mrugiero (guest, #153040)
In reply to: Versioning packages for breaking upgrades by rschroev
Parent article: The KeePassXC kerfuffle

> The reason for stable releases is that they are stable, and that does indeed imply that there's a lot less stability from one stable release to the next. Breaking changes are sometimes unavoidable, and by having stable releases those breaking changes happen between stable releases. That doesn't mean we have to have breaking changes; I'll argue we should strive to keep that to the absolute minimum possible.

Breaking changes for the sake of it, right, undesirable. But they do happen and they are expected between stable releases, and they are expected in unstable. The whole point is that you have stability as long as you don't migrate to next stable, not that the whole distro is forever stagnant.

> I have to admit, I do see a point there: in the scenario where keepassxc keeps it full functionality and a new package keepassxc-min is created, people who don't read the detailed release notes (i.e. when it comes to desktops most people, I assume) would never know about keepassxc-min. Whereas in the scenario where keepassxc loses its functionality and a new package keepassxc-full is created, people would quickly find out that their use case is not supported anymore, and will hopefully quickly find out that they can transition to keepassxc-full.

And that's precisely the point. The package manager was designed precisely to allow this. You have transitional packages to force choices, software that informs you of manual intervention you may require, and a release model that doesn't push such changes to a given stable release. But at the moment you opt-in to upgrade, you are expected to give care to such possible breaking changes.