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

[Frank Crawford]

Just on the repository format migration option just consider that if
automated, then when packaging it for RedHat, and probably other
distributions, it should be non-interactive, and preferably easy to
tell if it is required or not (for example if they did a reinstall).

Also, as you have found, no one reads the release notes, so very few
will read that they need to run anything for a migration, and so we
will almost certainly need it to be done automatically, either by
rdiff-backup, or just when upgrading the package.

Regards
Frank

On Sun, 2023-02-26 at 18:49 +0100, EricZolf 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
> >