Re: dependabot and Newtonsoft.
I’ll not merge these PR if you don’t want to.
However, it will not accelerate PR handling if I don’t merge these PRs. What time I win with not merging these PR, I will use on other stuff. I think I have made clear that I am not keen on merging features, only on clear breakages.
However again, the 4 year lapse between 12 and 13 version has been used by the Newtonsoft project for bug fixes. It’s not a good idea IMO to forgo these bugfixes because they are not explicitly marked ‘security’. In 4 years, it don’t happen that the code has not been made more secure, unless the project is not used at all. That’s hardly the case for this project:
https://www.nuget.org/stats/packages
it’s the most used on Nuget. By a large margin.
And if you browse the downloaded versions (600 K per day - it’s a trusted project if there is one):
take a hard look at this page. I know that you are observant I’m sure that you will not miss the interesting detail 
Enough about Newtonsoft from me, next to plans.
Now that I am a Duplicati developer, I have a small change of mind about the planned release.
In my opinion, the current canary has been tested more than enough, so long indeed that several problems have appeared because some stuff has been obsoleted. The plan in my idea should be to refresh the canary to fix these problems, publish it, then after a short time (one month) go to beta (finally).
There is no need to add new risks to this (very near I hope) beta by merging left and right. The more so because I’m not ready to evaluate complex changes.
So the breakages to handle IMO:
- there is a missing fix in the committed stuff post last canary (104) by Albertony
- mega nz: update the library
I wanted also to include Add a few more compressed, audio, and video exclusions by dgasaway · Pull Request #4815 · duplicati/duplicati · GitHub (very low risk) and update other libraries. I hope that you’ll not object to the Storj update:
It has been asked for and here I am for the merge since it’s a library .
What I wanted initially is to add to bug fixes a small improvement as a proof of concept that Duplicati could go forward (even slightly) by merging my perf experimental code.
But having seen the involvement of posters on this forum about the missing tray icon on OSX, I think that it’s better to try to get this in, because first it’s currently broken, so risk of regression is minimal as it can’t be worse than not working at all, second it’s really an improvement involving added code so it’s as good as a proof of concept.
So I plan to review it as an exceptional case - even if I don’t plan to do this in the following months except in case of breakages because I expect to do other things with Duplicati (*), I’m going to test if it regress on other platforms (at least Windows and Linux - done), and if we have a few confirmations that everything is all right on Mac by posters, I’ll commit it instead of my ‘performance’ PRs.
Also (last reason but not least), if I advocate team work I should avoid committing my own changes. In well managed projects, one don’t commit own stuff, another contributor reviews the PRs and commits - even if it’s sometimes formal, it’s better than not caring at all.
Finally for the immediate plans: please give me your final answer about Newtonsoft, I’ll create a synthetic PR regrouping all the planned changes (including or not Newtonsoft), and push it to my test repo, so that binaries could be available to test the next canary (105). As you’ll notice, the test repo now generates binaries for all 3 main platforms, although I can’t test MacOS binaries:
But I have already tested the generated installers for Linux and Windows and they seem to work all right.
(*): getting better at understanding Duplicati code, understanding the OAuth server, preparing for Kestrel…there are quite a lot of things to think of. It’s just the only thing possible to do the minimum to keep the boat afloat, unless there were half a dozen more developers.