[mythtv] Backwards compatibility

[Lawrence Rust]

On Wed, 2016-01-06 at 18:59 +0000, Paul Harrison wrote:
> On 05/01/16 18:36, Lawrence Rust wrote:
> > Hi all,
> >
> > Over the holidays I've been thinking about how to increase the amount of
> > testing that the master branch gets.  One of the common stumbling blocks
> > to more universal acceptance is that many Myth users have a 'production'
> > backend running an older version, often 0.27, which is incompatible with
> > the latest Myth protocol and database schema.
> >
> > Proper testing of the master branch requires the setting up of a new
> > backend with tuners etc.  Many potential testers are unhappy disturbing
> > their 'production' backend that is used for daily recording - me
> > included.  Indeed, in the course of developing the Raspberry Pi frontend
> > I could have benefited from testing with a live BE,  What's more, I have
> > been asked several times whether there was a way to have the master
> > branch code work with a 0.27 backend.
> >
> > This set me thinking - how difficult would it be to achieve backwards
> > protocol and schema compatibility for the frontend?  So over the weekend
> > I tried some ideas:
> >
> > 1. Enable read-only access to old old database schema.
> > 2. Fallback to an old version of the Myth comms protocol.
> > 3. Provide a translation layer for updated protocol requests
> > 4. Provide a translation layer for serialised data structs.
> >
> > I've made a new branch devel/lvr/backcompat.  The current state of
> > affairs is that I can connect to my production BE and watch recordings,
> > livetv and videos.  After creating a Music SG I can also play music.
> >
> > My question is: Is there any mileage in this for general use?
> >
> > Comments and suggestions most welcome.
> >
> > -- Lawrence Rust
> >
> 
> It's kind of telling the only replies you got are from non developers 
> who don't have to maintain this :)

I suppose that's expected.

> Are you talking about keeping master backwards compatible to the 
> previous release or beyond that like some are suggesting using a master 
> FE on a 0.26 or 0.25 BE.

My initial thinking was only to be compatible with the previous release
i.e. 0.27.  However, it became clear while fleshing out the code that
it's almost as easy to support 1 previous version as it is several (as
versions increment over time).  It would be sensible to remove support
for very old versions to keep the size down.

> I would mildly be in favour of keeping master backwards compatible to 
> the previous version since that would be useful for developers and 
> testers but only if it could be done without complicating the code to 
> much or make it to hard to maintain or too much trouble to add new 
> features to master because of all the extra testing that would be 
> required to maintain backwards compatibility.

It isn't really too burdensome for future development.  There's no need
to be perfect about the upgrade path, in fact deliberately breaking some
functions is useful for error testing.  The main work areas are:

- Handling errors when a Myth protocol gets updated.
- Returning sensible values if a new feature isn't implemented.
- Protocol version dependent de/serializing data.  This isn't too
onerous from current experience
- Schema dependent database queries.  This is made simpler by replacing
missing fields with constants.

Currently there are 3 patches covering 23 files changed, 679
insertions(+), 56 deletions(-).  Not exactly a big change.  With that I
can use almost all FE functionality.  I haven't bothered to translate
many upgraded functions so the log is full of error reports, but that
doesn't matter - the user gets to test the new features, the database is
preserved and lots of dark corner cases are covered.

-- Lawrence Rust