peter: > > Whenever we need to deliver a updated app to customers whose OS is > > too old (but updating it is too risky), we could either > > a) keep evenly outdated dev build OSes around forever (oh no!), or > > b) post our newly built app in a container (leaving the lovely native > > world); and both ignore the fact that customers wish maintenance of > > the entire OS actually, too. > > So, ideally, there is c): In a hypothetic case we would prepare a > > entire OS incl. our app (maybe via catalyst?) which would require > > a bootloader-like mini-OS on the customer's side, to receive updates > > over the internet, switch the OS at boot time, and fallback. > > I had a) in mind. Why "oh no!" ? I didn't mean forever.
Why "Oh no": Well, it works and we are currently going that way. But see the other discussion branch in this thread: It's just a growing maintainment mess over time. In short: Too many OS versions resp. according dev VMs to rebuild new apps against it. > catalyst building specific, "old-like" OSes on which you build new (binpkg) > versions of your app to be installable by emerge on old customer OSes is > admittedly a lot of work, at least initially. Yes, that brings in another approach: *If* we had catalyst controlled versions of the (already...) delivered OSes, we could maybe setup a CI/CD like pipeline to re-create the according developer VM (for building a updated app with the exact old dependencies as on the formerly delivered old customer OS). So to say: VM just in time. Well I'll keep that in mind. That may help against the VM mess (see above). But building exact (older) OSes still requires a solution to distribute the entire OS incl. app remotely and savely. See also the other discussion branch on that if you like. Thanks
