Package: debian-policy Found: 4.7.2 Officially Debian does not support skipping major releases when upgrading from one version to another, as noted in https://www.debian.org/releases/trixie/release-notes/about.en.html#introduction
> Please note that we only support and document upgrading from the previous > release > of Debian (in this case, the upgrade from bookworm). If you need to upgrade > from older > releases, we suggest you read previous editions of the release notes and > upgrade to > bookworm first. Debian is however commonly used in long-lived physical instances, and it is common for users to aim for maximally stable systems and minimal amount of changes, often leading to users also skipping releases. Even though not officially supported, it does often work, as documented by a DD in e.g. https://diziet.dreamwidth.org/13087.html Upgrading from Buster to Bullseye is known to work with a small workaround that was documented in https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#libcrypt-upgrade-from-buster Jumping from pre-Bookworm to Trixie is extra hard due to the usrmerge changes done in Bookworm, but it is possible. There was also libcrypt1, glibc and util-linux changes in these versions that causes extra challenges, see e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993755 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975077 A CI system that does this in a container environment (where renaming /bin and /lib is often impossible) and succeeds with some workarounds can be seen live at https://salsa.debian.org/debian/entr/-/pipelines/ upgrading from Stretch all the way to Sid. I propose the Debian policy to include some kind of generic statement, that while skipping releases is not supported in the sense that it is not guaranteed, packages should avoid dropping backwards compatibility code purely for the sake of cleanup. Code that facilitates upgrades and backwards compatibility should be kept around if there is no special cost to keeping it, and if the code facilitates upgrades from a version currently still in LTS or ELTS support. Example to illustrate "cleanup only" changes: https://salsa.debian.org/debian/util-linux/-/commit/54cba9a31bda49a0b98048d9598cc6f70bd1ee1f For packages targeting Trixie+1, code that is needed for upgrades from Buster should still be kept and not cleaned away (see schedule at https://wiki.debian.org/LTS/Extended). The policy should be clear that the ability to upgrade is nice-to-have and beneficial to users, and packages should not rush to clean up code that does not really require any maintenance in new versions, as removing such code is guaranteed to break upgrades from old versions and essentially fully prevent users from skipping upgrades. Debian is not famous for having the latest and greatest of everything. Debian is however trusted to be rock solid and extremely stable, and a good foundation for long-running systems with high stability requirements. If the policy recommends that backwards compatibility should be kept and not removed just for sake of cleanup, it would serve well Debian's users who often chose it because of the very stable nature and conservative update policies. - Otto
