Issues to address to get out of beta

That’s a what-if with blockers, I’m wanting to understand if there are currently blockers for putting a new canary or beta out. Like you said, that’s a question for the person handling releases.

For canary, if release documentation is desired that’s fine, then there should be automated nightly builds. IMHO early and often builds should be getting out to testers.

“Blockers” is ambiguous. I proposed two “blockers” as in “suggest-waiting-for-fix”. Any others? Where is:

Fix pausing and stopping after upload #3712

Stopping immediately also works but due to issues of corrupting the database when aborting, the stop now button has been removed until the corruption issues are fixed.

Fix ‘stop after current file’ #3836 is being actively worked, I don’t know if its impact is as bad as above one.

Anybody else have nominations for fixes that you really want to fit in next release? If so, please describe it.

If you mean non-code “blockers” from process viewpoint, we can use more thoughts. I gave one person’s, and his “anything meaningful” part is what I hope one can view by seeing closed items on some milestone. Such items would have been largely pre-chosen as worthy of planning, thus likely worthy of a release note.

In addition to Pectojin Discussion: release cycle, here’s my view from Release: (beta) 2019-07-14:

Those are already broken in the current beta release. If some things are not fixed why hold up a beta release when other items are ready to go? Not everything needs to be fixed to deliver a new release.

I’m not sure I’m understanding the requirement need to be met for a new release. If there are incremental fixes get them out. For issues still not fixed then like other projects, put then in the release notes as “Known Issues”. We certainly will not want to knowingly push out a release that is worse.

I must be missing something. Thanks for your patience.

I likely confused things by referencing an issues post, then asking for talk on two others. Do you mean Issue1400 and friends one which is an old bug but very impactful as seen in impact analysis of issue?
That had so much advance work including analysis and proof-of-concept fix that it seemed worth a fix.

The FTP (Alternative) bug does not exist in the current beta. If you refer to both stop issues, they exist, however I wanted to see if anybody would speak to them as worthy of squeezing in, given, as you say:

This is exactly why I’m proposing we weigh the fixes versus not-yet-fixes. Some fixes just have to wait. Which of the issues (if any) do you think should get fixed before we PM kenkendk to release a canary?

This is exactly why I was lobbying for just an incremental fix for aftp instead of TargetFramework move, however the consensus of those with opinions (including on current thread) seemed to like bigger step.

What I’d really like would be to fix the beta blockers (including the aftp backend fix I keep mentioning

Reasonable idea if we get better at release notes (volunteers?) and can filter 800+ issues to limited list, possibly an “Errata” idea with known workarounds, and other issues at least having to be describable… Describable issues might also be candidates for a milestone. Random breakages are hard to deal with.

Anyone else have input? You want to PM for a canary right now, or if not, then what should be awaited?

As long as the current master branch has no known additional bugs then I would say do a canary release and wait for no other PR’s, just get the canary out. There is no need to wait for the .net462 framework move, that can go in another canary release.

There doesn’t seem to be a reason to hold back a canary or beta release.

Regarding AFTP, according to that link the that bug was known about by at least July 3rd and the last beta was July 14th. The AFTP bug is not in the current beta?

It was made in v2.0.4.16- is basically Release note:


Changes in this version:
This update only contains warnings to inform users on Amazon Cloud Drive that the service is discontinued.

To confirm that, click for what latest beta brought, compared to November 2018:…v2.0.4.23-

I’d like to know how others feel. I don’t know of other issues holding back a canary, but I’d want to get another canary soon to fix the aftp regression and the huge corruption fix which is the Issue1400 one.

Question is – what’s the Canary plan before Experimental and Beta? More Canary == a slower Beta, however the post that Pectojin commented on pointed out that in times past Canary came very often:

before new versions were are released every week

although I don’t think kenkendk would like the rapid pace because he’s incredibly busy at the moment.

What does everyone think about the path to Beta? There’s also forced Google Drive issue (still TBD).


Release has link you can click to see what’s changed since then, but go back too far and it overloads.



I’m not seeing anything too earth-shattering after that, though we’d lose some good fixes if this was called Experimental. canary actually seems canary-adjacent to experimental which I think was canary. Alternative beta push would be to say testing is enough, and beta at code. Code prior to would lose fixes for backup-breaker Upload throttle corrupts backup, especially OneDrive. Analyzed, with code proposed. #3787 and database-breaker “Unexpected difference in fileset” test case and code clue #380, and those look pretty critical, if we agree we want to focus on those breakage types.

Pushing past onto current master fixes an occasional restore-breaker Hash mismatch download corruption, likely from throttle buffer offset being reused #3782 and limited backend-breaker Backends are not disposed after upload operations #3808, plus DB bug report code keeps original FileLookup Path intact (privacy regression) #3790. Shall we pick those up too, then try Canary - Experimental - Beta and perhaps release-note aftp not working when server OS has different line endings than Duplicati has? Not sure I want to release note the Issue1400 and say we decided to Beta without it, so they get to wait…

I don’t know of any issues currently that should block a canary release. I think we should get a canary out soon.

The pull request from @BlueBlock fix for the very painful Issue1400 went into master an hour ago via @warwickmm and I’m not going to push hard for standalone FluentFTP update, but it’d still be nice if it can squeak in if anyone will do it. The FTP (Alternative) users can (to some extent) move to regular FTP instead, and I’m not certain what fraction are affected anyway, extrapolating from a single canary report.

Most common client OS is Windows, so main server mismatch may be if Linux FTP (e.g. NAS) is used.

@warwickmm would you like to ask kenkendk for canary? I’m not sure how fast he can do that anyway.

Doesn’t this PR fix it or is there another issue? #3866

AFAIK it requires FluentFTP 26.0.0 to pick up this fix, which isn’t exactly what I described, but might work:

OpenRead with EnableThreadSafeDataConnections = true does ASCII when it shouldn’t #428

The 3866 PR does not look like it does anything to fix FTP mistaken conversion between OS line endings. That is entirely as expected, because this was a bug in the .dll that was exposed in Duplicati canary code.

PR Update framework to 462 #3844 updates from 21.0.0 to 27.0.1 but is being proposed to not hit canary. Latest FluentFTP version is 27.0.3, and I haven’t looked to see what has changed since 26.0.0.

I see… thanks. That would seem to be an important fix to get out for those impacted.

Yes, although the impact is unknown. Avoiding breaking such users is one reason why was just plus a warning. Of course, the other big reason for not going Beta was Experimental and Canary only had about two weeks of testing, whereas now they’ve had about two months and seem to work OK.

For past FluentFTP background, please see current post here or the framework update discussion here.

I’ve asked ken about creating a canary release. Hopefully he will be able to find some time in his busy schedule.

To add to the request… it sounds like there was an attempt at having an automated release process… if not used for canary it would be great to have it for nightly’s. It’s important to get fixes out to some testers as soon as possible since not all testers want to perform builds to get the latest for testing. It reduces friction for the testers.

Agree. I’m still not set up for builds, but there are times when I’d like a nightly, e.g. if I can talk someone into a FluentFTP update (to see if that can get there before the canary build does…). It’d also be great to have more testers at any release level – preferably people with some expertise and an ability to file good issues.

I’m not certain unit tests are the mechanism, but I don’t know how Duplicati’s focus. Sometimes a “stress” test (thinking of “pounded”) is a different thing, and may require more equipment than a typical person has. There is occasionally talk of shared resources for the team, but who’s going to manage the infrastructure?

By pounded I’m thinking putting Duplicati in less common scenarios but still very important, such as killing the process during backups etc. to try and find any weaknesses in the file and database handling.

1 Like

@ts678 and anyone else, what do you see as the top 3 -5 listed issues on github that need to be fixed?

I have the (personal) signing key, so I need to do the releases. I have set it up so it is just a matter of running the build script (takes ~15min) and then a new build is uploaded.

But sometimes things fail or have changed, so I need to track that down. I have put out a new release based on @warwickmm’s request, but the update to .Net 4.6.2 broke the Windows build server.

I try to get the canaries out regularly, but if I am behind, please send me a PM and I will do it asap.

As I mentioned elsewhere, @verhoek has set up a system for fully automatic nightly builds. It should be a matter of working a few hours to get it running.

There is a fix/workaround for AFTP in the new canary. Is this fix sufficient to go with a new beta? And if so, should we base it on the newest experimental or go “canary -> experimental -> beta” ?

This “just one more thing” is usually what prevents getting a beta out, but maybe someone (i.e. not me) can make a good argument for what goes into the beta.

You mean for a stable release I assume?

I only have the “repair speed and stability” issue. But it sounds like some of it is fixed already.

Is this something you’ll need to do or can others assist? I suppose if it is a build machine then just yourself.