[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Survey: compatibility vs speed of rdiff-backup development
From: |
EricZolf |
Subject: |
Re: Survey: compatibility vs speed of rdiff-backup development |
Date: |
Sun, 26 Feb 2023 18:49:35 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 |
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
compatibility_vs_speed_of_rdiff_backup_development.ods
Description: application/vnd.oasis.opendocument.spreadsheet
compatibility_vs_speed_of_rdiff_backup_development.pdf
Description: Adobe PDF document