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
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

I beg to differ. Having tidy packages reduces bugs, improves general
quality and eases collaboration.

There is no such thing. "dead code" is always a maintenance burdern,
even if it is only that when reading/looking over it is annoying and
takes more time/distractions to wrap your head arround it.

not that I think this is particulary true when comparing Debian stable
with e.g. Ubuntu LTS or distributions with similar security support..

..but for the sake of the argument (rhetorical question): just because
versions of upstream packages are old we should let our own packaging
rot too? I don't think so.

Regards,
Daniel

I wanted to reply to the original message with "I explicitly want to
oppose this", so I'm glad Daniel already did.

I agree with all these opposition points. I also want to point out
that any intent of not-not-supporting skip-upgrades will demand
users support for them, and by extension cause an explosion of
untested upgrade scenarios. For which we already have no good
testing for the simple cases, and anything more complicated will
just cause pain for everyone.

Chris

You need to explain the advantage of skipping a release instead of performing
two upgrades back to back as recommended.
Whatever policy says, the less tested an upgrade path is, the more likely
problem will appear, and we barely have enough time to test upgrade already.

Most of the important transition require preparatory work in release n so that
the upgrade to n+1 is smooth, so they need to be done before release n is made
stable, which require a two-years lead.  Supporting direct upgrade to n+2 would
require a four-years lead which is not sustainable.

Cheers,

[ trimming CC and sending to the bug number ]

Hello.

For a long time I used to think like you, Otto, that supporting
upgrades which skip releases would be "nice".

It was Steve Langasek who finally gave me a good argument against
that: By encouraging or supporting that, we would be sending the wrong
message to our users, namely, that it's something that they could try
to see if they have luck, when in fact it's something we would much
prefer nobody to do for the reasons stated by Chris here:

Indeed. The number of possible upgrade paths is almost infinite.

So, I also think this is not a good idea.

Thanks.

I imagine there are many more issues with a skip upgrade from Debian
10 to Debian 12 than the one documented there.

I agree with those saying that the Debian Project should strongly
discourage skip upgrading.

However, it would be polite if upgrade handling (like Breaks/Replaces)
be kept until it has shipped in both the latest Debian stable release
and the latest Ubuntu LTS release.

Thank you,
Jeremy Bícha