Tim Cross <theophilusx@gmail.com> writes:

> At the same time, us users also need to take on some of the
> responsibility and recognise that major version upgrades may break or
> change their workflow. If you have a situation where stability of your
> environment is critical to your work and your strapped for time so that
> any change will be unacceptably disruptive, you need to adopt an upgrade
> workflow which mitigates that risk.

I had that on an OLPC where I had everything working and avoided any
changes that weren’t necessary, because I used it for writing. It was
perfect. There was a catch, though: It used a custom kernel and the
config did not work with newer versions. And I did not manage to change
that with some 20 hours of trying. But that did not hurt me, I had my
emacs and could play music for writing and roleplaying games.

Then the config for the new Emacs version on the desktop and the version
on the OLPC became incompatible, so I upgraded the OLPC to be able to
transfer the changes (I needed them so I could use the config in the
repository to be able to run the exporter for the writing — I also had a
full texlive on there). That was right around the time udev got
introduced as mandatory dependency. And that needed a newer kernel to
avoid breaking the audio.

I have not been able to restore sound output to the OLPC in the past
half decade. And all ways I tried to fix the problem — including other
distros — failed in some ways.

Sad story short: Having to update is a fact of life. Stuff that breaks
                 on update is a liability. Most of the times org-mode
                 has been pretty good at it, but the few breakages it
                 had did actually cost me quite some time (one example
                 is that lecture-slides did not export cleanly anymore
                 after the exporter updates).

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken