<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 5, 2016 at 8:33 PM, Lawrence Rust <span dir="ltr"><<a href="mailto:lvr@softsystem.co.uk" target="_blank">lvr@softsystem.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, 2016-01-05 at 14:25 -0500, Dan Wilga wrote:<br>
> On 1/5/16 1:36 PM, Lawrence Rust wrote:<br>
> > This set me thinking - how difficult would it be to achieve backwards<br>
> > protocol and schema compatibility for the frontend?  So over the weekend<br>
> > I tried some ideas:<br>
> ><br>
> > 1. Enable read-only access to old old database schema.<br>
> > 2. Fallback to an old version of the Myth comms protocol.<br>
> > 3. Provide a translation layer for updated protocol requests<br>
> > 4. Provide a translation layer for serialised data structs.<br>
> This is a great idea, Lawrence. I know I am much more likely to try this<br>
> than I would be to replace my working BE with 0.28.<br>
><br>
> Is there any chance the 0.28 code could run a *slave* BE talking to a<br>
> 0.27 *master* BE?<br>
<br>
</span>This is distinctly possible - not with what I have now but with a little<br>
bit more effort.<br>
<span class=""><br>
>  That's another scenario under which I could test. It<br>
> would even allow me to temporarily reassign my tuners to the 0.28 slave<br>
> and try recording.<br>
<br>
</span>That's what I was hoping - a more diverse test environment exercising<br>
all the corners.<br>
<span class="HOEnZb"></span><br></blockquote><div>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.<br><br></div><div>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..<br></div><br>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.<br><br></div><div class="gmail_quote">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).<br><br></div><div class="gmail_quote">Just my thoughts, I may ask the users-list what stops others testing out the master branch.<br><br></div><div class="gmail_quote">John<br></div></div></div>