Re: [gentoo-dev] Gentoo LTS or: proper backward compatibility?

[m1027]

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