Re: Backward compatibility of next beta

[Patrik Dufresne]

I also understand the pain regarding non-backward compatibility between the 
two versions. In terms of migration, it becomes a lot more complex if both 
ends need to run the same version.


I didn't take a look at the technical details behind the incompatibility. 
I'm trusting Frank and Eric on this topic and understand it's not an easy 
fix to make v2.0.0 compatible with v1.2.8. You must understand it's a draw 
back of a bad design in rdiff-backup from the start.


I'm in the same boat as many of you, I have more than two hundred servers 
using rdiff-backup directly or through Minarca and it's impossible to 
migrate all of them at once. I've been thinking about a migration plan for 
some time now and I have a general idea that I can't wait to put in place. 
I'm planning to work on a solution end-February. The general idea is to 
pre-compile rdiff-backup 1.2.8 and 2.0.0 as individual executable and 
deploy both of them on the central server as rdiff-backup-1.2.8 and 
rdiff-backup-2.0.0. Then reconfigure the SSH server using a script to 
either call rdiff-backup-1.2.8 by default and call rdiff-backup-2.0.0 based 
on some condition.

On Thu, Jan 30, 2020 at 10:03 AM Derek Atkins <address@hidden> wrote:

> Frank Crawford <address@hidden> writes:
>
> > No, the use of "--remote-schema" is the issue as it passes data between
> > the two programs in a specific format that has changed between python2
> > and python3 because of internal variations.
>
> So what data specifically changed?
>
> > Regards
> > Frank
>
> -derek
>
> -- 
>        Derek Atkins                 617-623-3745
>        address@hidden             www.ihtfp.com
>        Computer and Internet Security Consultant
>
>

-- 
Patrik Dufresne <address@hidden>