Re: Survey: compatibility vs speed of rdiff-backup development

Hi,

the results for this survery are not as nice and tidy as for the Windows 
"bitness". The numbers are attached (with the summary as PDF for 
whomever doesn't have LibreOffice), and here is my interpretation:


== Introduction

For both questions, I've calculated the percentage for each option, as 
well as the weighted percentage (i.e. according to number of clients). 
I'll present these two numbers as C%/W%.

In the following lines, I'll summarize the summary and give you my 
conclusion, feel free to argue.

== Repository format

88%/70% of the answers are OK with changing the repository format in a 
non-backward compatible manner.
The two persons who didn't agree were actually more talking about 
archiving than about backup. If you need an archive solution, please 
make sure that you keep an old version of rdiff-backup parked somewhere 
(together with its dependencies etc). With a bit of magic, it should 
even be possible to do this as part of the backup itself.

So for this point, my idea currently is to have an approach similar to 
Android (and other frameworks): write snippets of code, of which the 
only purpose is to upgrade a repo from one version to the next, so that 
by applying the snippets one after the other, you can upgrade any repo 
to the current version. This could be done transparently when creating 
the next backup _or_ with a specific "upgrade/update" command.

== API versioning

Here the result is less to my liking, but OK: 31/50% of the answers are 
in favor of keeping the 200 API hence the compatibility with 
rdiff-backup 2.0. This will have a negative impact on my speed of 
development, but fair enough, I understand the comments asking for more 
time to migrate all clients.

QUESTION: have you considered the side-by-side installation and the new 
{Vx/y/z} place holders for versins as you gave this answer?
See 
https://github.com/rdiff-backup/rdiff-backup/blob/master/docs/migration.adoc#side-by-side-installation

I'm asking again because the old code is really getting in my way, and 
I'm not yet sure that I'll be able to keep the backward compatibility 
without major risk to the code quality. I'll do my best, I haven't yet 
tried hard, time will tell.

== Further thoughts

The format of the repository and the API are somewhat tied together: new 
features might have an implication on the repo format, and might require 
also API extensions to allow client and server to express the new 
feature. I'm still thinking about a good (and simple) way on how to bind 
all these aspects. If someone knows of a good example on how to do this, 
let me know...

Any further thoughts welcome, thank you so far for taking the time to 
provide feedback,
Eric


On 11/02/2023 12:24, EricZolf wrote:
> Hi,
> 
> before I start for real with the development of version 2.4, I'd like to 
> get your opinion on the exact direction to take:
> 
> https://framaforms.org/compatibility-vs-speed-of-rdiff-backup-development-1676028206
> 
> I'd appreciate to get numerous answers and opinions. Feel free to also 
> discuss and argue on this mailing list.
> 
> I'll share the results on this list but they're public anyway.
> 
> Thanks, Eric
>