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

[Patrik Dufresne]

At that point, the best approach to keep you free from the old code and
move forward would be to "support" v2.x for a while and start working on a
v3.x version that will not be backward compatible and will require a
migration. And allow packager to install them side by side.

To reduce the friction I think it's the best approach.

With terabytes of data being backup with rdiff-backup, I cannot afford to
have a tool that is not reliable. I prefer reliability over new features.

Did you only get 16 answers !?


On Sun, Feb 26, 2023 at 12:50 PM EricZolf <ewl+rdiffbackup@lavar.de> wrote:

> 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
> >
>


-- 
IKUS Software
https://www.ikus-soft.com/
514-971-6442
St-Colomban, QC J5K 1T9