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