Roger

It seems to me that the solution is to replace all the OpenSUSE repos with a private repo you control that all your customers use. That way all stay on the same version.

When they want to do an update - they just update their repo and have their customers do an update.

This is what you have to do to test that all is good and not broken before you update the field. and your update plan works.

My 2 cents

I suspect most slowroll users do not have unlimited internet or they have slow internet and cannot stand to have 1500 updates every other week. Slowroll is probably intended for them or all of them will move to some other long term stable Linux like Mint or Manjaro.

On 2023-09-25 09:57, Roger Oberholtzer wrote:

[...]

On the other hand, we have measurement systems that are not office bound
(road condition measurements, mobile mapping, etc). They need to be stable
as we can make them. And, it is not convenient to update them regularly as
they are in the hands of customers. So we usually choose a Leap release

[...]

We had toyed with using Tumbleweed in this context. Unfortunately, the
rolling release that I like so much on my desktop is a problem in this
other use context. Getting all measurement systems to have the same
Tumbleweed snapshot at the same time is like herding cats. As we deliver a
binary installer, matching library versions across independent Tumbleweed
versions is near impossible. Also, our current approach does not require an
Internet connection at any point in the system build/maintain process.

[...]

That is a super interesting problem to solve. I suspect that MicroOS can help you to develop a solution where you can control when and where to update, and minimize the ABI issues with some static compilation / container (or with more work, using a multi-release binary for each of the supported snapshots)