That’s not really true. Ubuntu Core is a system comprised of the boot base (usually core*, eg. core20, core18), compatible kernel and gadget snaps, and a number of assorted snaps that implement the actual functionality of the device (eg. nexcloud, node-red etc.). The system is described using model assertion (a document signed with your keys) which lists all those snaps, declares the channels they track, and declares the security constraints (tracking channels for each snap and security constraints are UC20+).
The boot base (core18, core20…), and the reference kernel and gadget are usually based on the LTS release, eg. core20, pc-kernel from track 20, pc gadget from track 20 are all based on packages that are available in Ubuntu 20.04. Since those are LTS releases, the packages get maintenance updates and thus the snaps are updated as well. Those basic snaps are thus effectively maintained, updated, QA’ed by Canonical. This is where you benefit from the extended maintenance cycle.
The application snaps are at the mercy of their publishers, but having access to a specialized device store you have a range of tools to control how those snaps are updated, verify their compatibility, or pin their versions.
This is a basic maintenance update operation, which is typically hands-off. Snapd takes care of pulling the snaps from the store and updating them on the device.
The cross release upgrade is more complicated, but can be addressed in a number of ways, all involve changing the model (a process we call remodeling). First, in theory you can just update your model to specify a new base/kernel/gadget, eg. core20 → core22 and 22 track for kernel and gadget snap (this is one fo the scenarios tested in snapd CI). Or you can produce a completely new model (with a new name) which lists all the new snaps, and change your device to it. When upgrading across releases you need to consider whether the disk layout is compatible, eg. UC18 → UC20 is complicated unless the gadget uses a compatible layout. However with UC22 being still in development, the UC20 → UC22 should generally have compatible disk layouts of of the box, at least as far as the reference devices are considered. In the end, as a vendor you can setup a device in such a way that later cross release upgrades very hard.
IDK the details of the paying customers, but the snapd test suite includes model assertions signed by me that exercise a remodel. There’s even a test which verifies UC20 to UC22 remodel. Perhaps they were confused about the permissions system, where some actions such as remodel can be initiated on the command line (which is what the test does) or through the API, while access to the snapd API is gated by the snapd-control interface, which by policy is not handed out to random snaps published in the global store. It’s the same policy that we do not allow kernel, gadget and base snaps to be pushed to the global store by random publishers.
