Re: Obsolescence Python 3.5 support plan

Hi,

On 06/06/2020 14:07, Frank Crawford wrote:
> On Thu, 2020-06-04 at 09:44 -0400, Derek Atkins wrote:
>> So long as there isn't a client-server wire-format incompatiblity
>> with
>> older 2.x versions, I don't care!  (I want to ensure we never make
>> that
>> same mistake again of a wire incompatibility due to a change in
>> underlying tooling).

Just to be clear: we will break interfaces also in the future but we
will do our best (but also not more) to break them across 3 versions
instead of only 2, giving you one middle version to do your migration.

Telling you anything else would be a promise to obsolete rdiff-backup.

> And the only way to do that is to move to your own protocol over the
> wire instead of using something that is tied to low-level python primitives.

I slightly disagree with this statement: with a concept of client/server
protocol version mapped to a pickle protocol version [1] we could
probably avoid the issue.

Actually, while writing this e-mail, I checked the code and noticed that
it's enforcing pickle version 1 so the issue isn't the pickle protocol,
the issue is solely the bytes vs. str vs. unicode change between python
2 and 3. There is not much we could have done about it IMHO.

> Saying that, doubt that pickles will cause issues in the near future,
> and so it is more likely to break due to change in function names
> within rdiff-backup.

We could enforce protocol 5 to infuriate our users but we won't do this
;-) Seriously, we should move to protocol 3 or 4 (known since Python 3.4
so no issue with incompatibility), it should improve speed and resilience.

KR, Eric