[mythtv] Backwards compatibility

[John McEntee]

On Tue, Jan 5, 2016 at 8:33 PM, Lawrence Rust <lvr at softsystem.co.uk> wrote:

> On Tue, 2016-01-05 at 14:25 -0500, Dan Wilga wrote:
> > On 1/5/16 1:36 PM, Lawrence Rust wrote:
> > > 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.
> > This is a great idea, Lawrence. I know I am much more likely to try this
> > than I would be to replace my working BE with 0.28.
> >
> > Is there any chance the 0.28 code could run a *slave* BE talking to a
> > 0.27 *master* BE?
>
> This is distinctly possible - not with what I have now but with a little
> bit more effort.
>
> >  That's another scenario under which I could test. It
> > would even allow me to temporarily reassign my tuners to the 0.28 slave
> > and try recording.
>
> That's what I was hoping - a more diverse test environment exercising
> all the corners.
>
> This is something I have been considering recently as well. I am probably
one of the worst offenders. I used to update to the latest version of
mythtv soon after it came out, ( often wanting the new features). I would
in effect run two backends for a short time in tamdem to minimise risk.
Then by mistake I let a 0.19 frontend connect to my 0.18 backend (auto
scheme update) and bit the bullet and didn't roll back. Changes to mythtv
have become more of a nice to have than a necessity now. I spent years on
0.19 until I updated to 0.24 when 0.25 was already out, I wanted to still
run my VIA M10000 front end. The upgrades always brought changes which
lower the WAF, as she could see nothing wrong in the old versions. I am not
going to try to update to at least 0.27 so I can try out the Raspberry pi 2
I got for Christmas, I have tried Openelec, but I really want a Mythtv
frontend not a kodi one.

But back on topic. In my opinion Mythtv should learn from the DevOps
bandwagon, and do smaller releases and more often, so the upgrades are less
of a burden and less of a risk. One step to help this would be to enable
different versions to talk to each other, . Perhaps the backend could be
split down to take on the idea of microservices (probably all running on
the same server though) so you have the masterbackend just controlling the
scheduling, and a separate service for the recording, another service for
the communication to the frontend etc..

A big step missing in my mind would then be a way to roll back the database
to the old scheme but keeping the current recordings, which would be easier
with smaller schema updates.

I wonder if providing a docker image for people to test with would help. I
don't know much about docker yet, but it uses aufs, so you should be able
to overlay on top of a working master backend to get a sudo live system
(without the tuner though).

Just my thoughts, I may ask the users-list what stops others testing out
the master branch.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-dev/attachments/20160105/bac0e2d5/attachment.html>