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 9/25/23 05:32, aplanas wrote: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 stableas we can make them. And, it is not convenient to update them regularly asthey are in the hands of customers. So we usually choose a Leap release[...]We had toyed with using Tumbleweed in this context. Unfortunately, therolling release that I like so much on my desktop is a problem in thisother use context. Getting all measurement systems to have the sameTumbleweed snapshot at the same time is like herding cats. As we deliver abinary installer, matching library versions across independent Tumbleweedversions is near impossible. Also, our current approach does not require anInternet 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)