Release: 2.0.8.1 (beta) 2024-05-07

kenkendk · May 7, 2024, 11:43am

2.0.8.1-2.0.8.1_beta_2024-05-07

After almost a year, a new beta build is ready!

Since we are switching the underlying framework to .Net8, this release will be the last that runs on .NET 4 / Mono.
The new releases will be built with the framework included for minimal dependencies.

Thanks to all the amazing contributors and community for supporting the project!

For this release the following major changes are included:

Updates to various third-party libraries: mail, Ssh.Net, RestSharp, FluentFTP, Sharp.Xmpp, Uplink
Improved error handling with interrupted backups and damaged local database
Removed defunct links and backends
Changed to MIT license and removed donation messages
Even more options!

As always, a detailed change list is in the project changelog.

kees-z · May 7, 2024, 11:58am

Thanks!
I’m a bit confused about the update channel. Is this a new beta, or is this update only for the Experimental channel?

kenkendk · May 7, 2024, 12:10pm

This is the beta build. I forgot to save the update note, so it says “experimental”.
Sorry for the confusion!

drwtsn32 · May 7, 2024, 11:35pm

Upgraded several of my 2.0.7.1 machines (Linux, Windows, Docker) to this version. No issues so far!

Taomyn · May 8, 2024, 6:43am

I’m currently on a Canary build, v2.0.7.103-2.0.7.103 so will it be ok to test upgrade to this beta on one or two of my systems?

kenkendk · May 8, 2024, 10:45am

I would not expect any problems with that update.

kees-z · May 8, 2024, 7:50pm

Where to find the full changelog? I can’t find anything other then the summary in this announcement, ending with “As always, a detailed change list is in the project changelog”.

kenkendk · May 8, 2024, 8:04pm

It is always embedded in the binaries. Either via changelog in the UI or via Duplicati.CommandLine.exe changelog

And also committed to the repo:

duplicati/changelog.txt at release/v2.0.8.1_beta · duplicati/duplicati · GitHub

kees-z · May 8, 2024, 8:24pm

The GUI returns exactly the same text:

To get the most recent changelog, I have to use duplicati.commandline.exe located in the C:\ProgramData\Duplicati\updates\2.0.8.1 folder, otherwise the changelog at the time of first install is listed. But this one also lists the same summary:

Same for the GitHub changelog.

I was curious about the “Even more options”, but what these options are doesn’t seem to be listed anywhere.

ts678 · May 8, 2024, 8:35pm

Are you cutting off the output below the “As always” line in the above two clips? It continues, for example:

github.com

duplicati/duplicati/blob/78ea50c8335772f2684ff39f8e44c22d2836322b/changelog.txt#L18-L22


      
          As always, a detailed change list is in the project changelog.
          
          2024-04-19 - 2.0.7.103_canary_2024-04-19
          ==========
          - Added microfix that adds a missing default value to the backup reports.

and so on, however far back you want to go. People on 2.0.7.1 Beta might stop after reading down to here:

github.com

duplicati/duplicati/blob/78ea50c8335772f2684ff39f8e44c22d2836322b/changelog.txt#L95-L100


      
          2023-05-25 - 2.0.7.2_canary_2023-05-25
          ==========
          - update Github tests versions, thanks @taz-il
          - Add Catalyst Cloud as an OpenStack target, thanks @Andrew Ruthven
          
          2023-05-25 - 2.0.7.1_beta_2023-05-25

kees-z · May 8, 2024, 8:40pm

Ah, I was confused about pointing to a “detailed change list”. I supposed this to be another list, while the details are just below it.
Thanks for the clarification!

kenkendk · May 9, 2024, 9:32am

It was this build I was summarizing:

Options changes:
     `--s3-disable-chunk-encoding` added to the AWS backend (only useful for some providers)
     `--full-remote-verification` changes from a boolean option to a tri-valued one. Existing configurations should not be impacted.
     `--aftp-log-to-console` and `--aftp-log-privateinfo-to-console` added to the Alternative Ftp backend (for debugging purposes only)
     `--repair-force-block-use` added to the database rebuild process (only for very damaged databases)

ts678 · May 11, 2024, 2:40pm

8 posts were split to a new topic: 2.0.8.1 update may request SSH/SFTP ssh-ed25519 host key reverification

EDIT 1:

If you see message that ssh-ed25519 32 host key has changed to an ssh-ed25519 256, with values to the right staying the same, this was a bug fix in SSH.NET to now display key’s length in bits, not bytes.

Technical discussion is available at the link above so that the release note can just summarize the result.

EDIT 2:

Replicating an unrelated-to-SSH answer that moved away while moving away the detailed SSH thread:

DCinME · May 10, 2024, 5:54am

Has the handling of temporary files in the tempdir location been changed in this version?

In particular, I’m curious about the dupl-usagereport-*****.json files that Duplicati would emit into this location. I use a run-script-after option to process these files, but some process in Duplicati appears to be cleaning these files up with each backup run, leaving only the one from the very last operation… whereas in the past this was not the case.

Taomyn · May 10, 2024, 8:31am

I was able to upgrade from the last canary to this on a Windows 2022 server using the MSI installer in service mode - only had time to quickly test the two connections the backups make: SMB share and Wasabi S3, both were fine.

I did see in the logs that the Xamarin.Mac.dll file was reinstalled and I had to delete it manually again.

Hopefully over the weekend I can test backup/restore, and also upgrade one of my Linux machines.

johnwbyrd · May 13, 2024, 4:18am

Please stop pushing out “beta” and “experimental” builds to all your users.

I do not want to be a beta user or an experimental user. I do not want whatever you consider your latest features to be.

I want a rock-solid, completely boring bit of backup software, that works correctly 100% of the time.

Taomyn · May 13, 2024, 9:06am

I checked the upgraded 2022 server and its backups worked fine. Then tested a couple of restores, one from the new backups and one from a few months ago, and it was also ok.

I now upgraded a Debian 12 server without issues, will see how the backups go and perform restore tests afterwards.

kenkendk · May 13, 2024, 8:17pm

The pushing of beta and experimental builds is the path to getting the rock-solid stable release.
When downloading any release (canary, experimental, beta, or stable) the updater checks that same type of updates.
Since we have (comically) never released a 2.0 line stable release, you have most likely downloaded a beta release, which is why it checks for beta releases.

Perfectly understandable. You can go to settings and set the channel to “stable”, then you will only be notified when a stable release is available:

Me too! ( the boring part is not mandatory for me )

My priorites are:

Update to .NET8
Stability
Performance
New features

We have made some progress on the first priority, so next up is stability issues. When these are handled, there will be the first official stable release.

johnwbyrd · May 14, 2024, 12:51am

As you see, the very screenshot that you posted makes no sense. There is no “base install” version; and the beta version is listed as the “most stable version available.” These definitions are not consistent with modern software development practices. See for example Debian’s stable/testing/unstable definitions for a more modern approach.

ts678 · May 14, 2024, 2:28am

There is after an install, but the definition is obscure. This is being changed during the move to .NET 8.
A base install is not a stability level, but the install from an OS package, such as .msi, .deb, and so on.

The base install has a channel associated with it, also visible in the file name, and the setting shown is
simply saying that if you installed from a given channel, the default is to keep giving you updates from it.

Channels are a current concept, for example:

Chrome Release Channels
Windows client updates, channels, and tools

The current autoupdate system lets Duplicati offer updates which are installed without admin privilege, however they are stored separately from the base install. The result, in About → System info, is these:

BaseVersionName and ServerVersionName which might be the same as the base without an update.

In the upcoming scheme, I think there will still be channels, but the update will be more like usual install.
This avoids having to explain how the base install runs the latest installed version of Duplicati it can find.
There were other problems too.

It’s listed that way because it’s true. It’s not yet in cycles like Debian. It’s a climb towards its initial Stable.
One thing I would say is that Duplicati has had a very long Beta, but it’s been very resource constrained.

Debian testing has a similar definition (but more formal), as they are fixing their issues to get to stable.
Debian’s first stable was released in 1996, possibly not rock solid, because software is rarely that good.

Duplicati, like most software, gets a flow of issues reported, but that’s from 65 million backups per year.
GitHub tracks the backlog, not every issue can be fixed at once, and the work priority was shown above.

Software is hard, and regular volunteers are often rare. This limits the speed of progress that is possible.
Everyone would like Duplicati to run perfectly, but wanting it doesn’t make it so, or possible to make it so.