[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Backward compatibility of next beta
From: |
EricZolf |
Subject: |
Re: Backward compatibility of next beta |
Date: |
Wed, 29 Jan 2020 06:49:38 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 |
Hi Derek,
your understanding is sadly correct but was always like this, because
there is no concept of API versioning (like we know in the mean time for
REST APIs). This is something we have on our roadmap but it's not an
easy thing to do, and definitely not with this release.
See
https://github.com/rdiff-backup/rdiff-backup/milestones?direction=asc&sort=title&state=open
In the mean time, I hope we can avoid further incompatibilities, but
it's not a promise.
Sorry, Eric
On 28/01/2020 21:45, Derek Atkins wrote:
> Hi,
>
> Frank Crawford <address@hidden> writes:
>
>> (Sorry about the previous formatting I'm resending this formatted
>> correctly)
>>
>> Rigo,
>>
>> It depends on what you mean by compatible.
>>
>> Python3 version of rdiff-backup is not interoperable for remote
>> operations with python2 rdiff-backup, so v2.0.0 will not work with
>> v1.2.8 or v1.3.3. This is a python3 vs python2 issue and could not be
>> fixed without major changes to both versions.
>
> So just to be clear, the version of "rdiff-backup --server" must match
> the other version? Right now I have a backup server that basically
> runs:
>
> rdiff-backup <excludelist> hostname_backup::<dir> <targetdir>/hostname
>
> Where "hostname_backup" is an SSH configuration, and it then uses SSH to
> connect to "hostname" where it creates and mounts an LVM snapshot and
> then runs "rdiff-backup --server --restrict-read-only /mnt/snap"
>
> Having said all this, what you're saying is that once ANY of my target
> hosts get upgraded to a point where they can only run
> rdiff-backup-2.0.0, then I must upgrade ALL most hosts (and backup
> server) to be running rdiff-backup-2.0.0?
>
> IMHO, that is a VERY VERY BAD THING.
>
>> However, the backup archives that are created are compatible, so if you
>> did a backup with an older version, you can continue using it with no
>> issues.
>>
>> In fact, while this isn't in the planned distribution, there is some
>> comment by someone who has written a wrapper that invokes either a
>> python2 or python3 version, depending on what it is talking to. Of
>> course the python2 version is either v1.2.8 or v1.3.3, not v2.0.0.
>
> I think this is extremely important to get into the release in order to
> handle the use case stated above! I certainly can't believe that I am
> the only person who uses rdiff-backup this way to back up remote
> machines.
>
>> Regards
>> Frank
>
> -derek
>
- Backward compatibility of next beta, Arrigo Marchiori, 2020/01/22
- Re: Backward compatibility of next beta, Arrigo Marchiori, 2020/01/30
- Re: Backward compatibility of next beta, Frank Crawford, 2020/01/30
- Re: Backward compatibility of next beta, Derek Atkins, 2020/01/30
- Re: Backward compatibility of next beta, Patrik Dufresne, 2020/01/30
- Re: Backward compatibility of next beta, Derek Atkins, 2020/01/30