[mythtv-users] Upgrading from pre-0.22 MythTV versions

[f-myth-users at media.mit.edu]

I've been pondering this for a couple weeks, ever since I saw Mike's
commit of 2012-03-09T15:20:56-08:00 and his message re "Upgrad failing
from schema 1214 to 1265)" [sic].  This is a new thread 'cause I'm not
sure if very late replies to old threads typically get seen.  Sorry if
this is a bit long, but thanks for whatever you can clarify.

I understand the problem with supporting old Myth versions if their
surroundings also change, but can you be a little clearer on a few
issues here?  And I'm hoping to perhaps change your mind, or at least
get workable ways forward---maybe support old versions until 0.25 is
released and -then- drop them, with more warning than the zero that
such users got before your commit?

First off, what was the actual problem with upgrading between MySQL
5.1 and 5.5?  And if it's now fixed in master, why -not- continue
to support that upgrade path?  Why deliberately break it?

My concern is several-fold:
(a) If Myth is like any other software project, there are a lot of
    users with old versions lurking.  Most probably aren't on the
    list.  Many have been coming out of the woodwork on issues like
    PVR-x50 channel-changing not working, long after many said,
    "Nobody uses those any more" but really only after none of the
    Myth developers used them any more.  (I still use them myself, but
    channel -changing- presumably wouldn't be a problem for me because
    I use baseband inputs from cable boxes, nor RF.  At least, I hope!)
(b) 0.25 has enough new features and capabilities that we might get a
    raft of upgrades.  I've been running a pre-0.22 version for a very
    long time myself, which has substantial automation around it and
    which is never used with HD, and so that old version has been good
    enough and not worth the pain of upgrading absolutely -everything-
    (can't use a 350 for output, can't use original hardware, can't
    can't can't -can't- etc), but 0.25 is probably worth it.
(c) When users with old versions -do- try to upgrade, they're going to
    have to find just the right version to upgrade to first, and get
    it all configured, just to upgrade, and -then- they'll have to
    upgrade again.  This is complicated by various issues---even if
    they don't go to the pain of getting their capture and output
    devices working in the intermediate versions, will the
    intermediate version start up without any?  Will they have to
    configure a dummy tuner somehow?  Will such intermediate versions
    be predictable about reaching out and -not- accidentally upgrading
    a production Myth while the user is testing?  (I know newer
    versions are getting safer and safer about that, but what's the
    status of 0.24-fixes absolutely never accidentally upgrading some
    much older other Myth on the same subnet?  I've lost track.  Do we
    at least have a list of -all- ports Myth might conceivably use to
    do an upgrade, so they can be blocked from escaping the test
    machine just in case?  Etc.)
(d) I know you've said you'll try to support doing intermediate
    upgrades, even if not "officially", but it sure seems to me that
    supporting them will be -harder-, not easier, for both you and the
    users trying to upgrade, since every issue they run into won't get
    patched into anything modern, so each new person will hit it over
    and over again.  And they'll need to find a distro from which they
    can still -get- an appropriate Myth version, which means most
    likely still more questions.  I'm hoping that an Ubuntu LTS
    version and mythbuntu might work well for me, but I know a lot
    less about how long every other random distro out there will still
    have the packages available to allow this to work at all.
(e) Taking Ubuntu as an example, will LTS releases (either Canonical's
    or MythBuntu's) inhale the bugfix you made to 0.24-fixes any time
    soon, and do they need to, or will users have to install an old
    distro, install 0.24-fixes, install dependencies, then hand-
    recompile and hand-patch so get the fix just so they can upgrade,
    all so they can then finally install a more-modern distro (e.g.,
    MySql 5.5 instead of 5.1, or whatever) and 0.25?  That's an
    enormous barrier and a lot of work and if they're asking questions
    all the way along, it sounds like a worse support problem than
    just trying to make such things work in master (and fixing master
    as you go, as people trip over issues).
(f) The other alternative, of course, at least if this particular bug
    was fixed in master, is for such users to install 0.25, install
    dependencies and -devel libraries, and then add in all the schema
    stuff you excised, and hand-recompile, in order to upgrade.  That
    might actually be a whole lot simpler, all things considered, if
    it works.  But of course then they're running an "unsupported"
    configuration and you'll yell at them.  But quite frankly it may
    be the way I'd try it first, if my end goal is to get to 0.25
    anyway and if this current issue is fixed in master.  Why make
    it so much more difficult in that case?

It'd be nice to get some "best-practice" advise on how to do this,
but I'll stop here for the moment.  Thoughts?