Stable version instead of beta?

1

I downloaded and installed Duplcati and it says version 2.0.4.23_beta_2019-07-14

Is there a STABLE download version that is a little older but is not in Beta that can be downloaded?

Thanks

2

So far there are no releases of Duplicati 2 that are called ‘stable.’ That being said, the beta versions are generally quite reliable.

A new beta will hopefully be released soon. They usually come out quickly after an experimental release, and a new experimental version (2.0.5.0) was just released today.

1 Like
3

Got it!

beta=good

experimental=use at own risk

Thank you

1 Like
4

And there’s also Canary… in general it would be the riskiest.

5

A new beta will hopefully be released soon. They usually come out quickly after an experimental release, and a new experimental version (2.0.5.0) was just released today.

Is there a way to follow the progress or efforts made to make a new Beta?

6

How closely do you want to follow? :wink:

Forum Releases category would have announcement. You probably see last one on your screen now:

Release: 2.0.5.0 (experimental) 2020-01-03, which links to GitHub, which links to commits since then. Seeing nothing horrendous there, or in new GitHub issues on 2.0.5.0, or in Forum topics, will probably lead to Experimental going Beta. Experimental can be feature preview, but I think this one is pre-Beta. When Stable eventually emerges, I hope this dual use of Experimental can be eliminated. We will see.

Progress and efforts at this point are the community trying out Experimental. Feel free to join if you like. People willing to take limited calculated risks on less important backups are what lead to Beta quality…

Settings will let you change to Beta channel if you like. Or just watch the forums and see what happens.

7

Well, I would like to be able to know more about:

  • If there are intentions to promote some version to Beta, and if people are working on it

  • Which tasks remain to be done before that can happen

  • Outstanding issues/bugs that need to be resolved before Beta release

  • How I can help

Thanks, this is useful. I checked on some level, and found:

  • Upcoming beta Milestone · GitHub which has a list of outstanding issues that need to be fixed before the next Beta release (1 item currently). It seems to be kindof what I am looking for. However, I suspect it is not being used actively for the 2.0.5.0 version at the moment.
  • No particular label for this version or anything related to Beta or “release”. I used search filters “is:issue is:open 2.0.5.0” to find open issues for that version. Is there a better approach?
  • No Forum posts that have unresolved issues due to version 2.0.5.0 (I searched for the version number)

I have some experience with open source software development, and I am used to a perhaps slightly more structured approach, such as: Someone volunteers as release manager. Release manager states intentions wrt. version numbering, type of release (maintenance, feature, beta, GA, etc), gives information on how to test, and gives some date when testing is expected to be concluded. Release manager periodically reports on issues found and state of bugfixes, or give links to bug system etc. Once all “blocker” issues are gone, maybe others as well, then a vote is made (if applicable) on doing the actual release.

I’m not saying I expect the same here, but I’m trying to figure out how to relate to the Duplicati release process in comparison.

Yes, I’d like to join the effort to try out experimental to the degree that I can.

Say that I have some backups that are not so important, and others that are important. How can I balance the need of having stable Duplicati with trying out experimental releases?
I expect having two instances of Duplicati running on the same host will easily lead to complications, or?

Once I have switched upgrade channel to Experimental, would it be possible to go back to Beta after some time? Which caveats should I expect if so, apart from not being able to use new features that are in Experimental only?

8

however the actual test of Experimental has been longer (which is reasonable, since rollout is slow).

We solved several, and I’ve heard of no more. I think we’re waiting for the release-maker to make it. Historically this move is slow. Promotion to Beta is based on less testing and feedback than desired.

Tasks and issues were primarily administrative, such as poll of staff, release note prep, version plan intended to prevent a repeat of the confusion where urgent tiny 2.0.4.5 Beta patch became 2.0.4.23.

Just running a somewhat unknown release such as Canary or Experimental and reporting bugs helps, especially if the bug reports are high quality such as giving complete directions for anyone to see bug.

Primary interest before release time is finding regressions of things that used to work, but now do not. Testing of features not in previous Beta also helps, but Experimental release note didn’t name them…

Volunteers are sought in pretty much all areas, including help with forum, better testing, development, documentation, etc. You don’t need to be a specialist, although specialists are certainly very welcome. There’s more than enough work to go around, and beyond bugs, there are abundant feature requests.

The Google Drive issue is still too fluid to be holding things up. Consensus seems to be Beta before it. How active this milestone will be in the future is TBD, and milestone is not always a hard requirement.

GitHub does ask for a version, but I don’t know if it’s anything more than a text field for human readers. Forum is even worse, and it’s very common for people to not provide version information. There’s also the potential that bugs in an older version exist in a newer one, so specific version search undercounts. Looking for version number might be a good way to spot new regressions, but it could just be old bugs.

How’s your experience with bug trackers? There are definitely better ones, but too heavy would be bad.

This is a good start, but see concerns above about free-form posts and carry-in bugs from old versions.

Canary/Beta Release Logic?

There’s an opening for a release manager if anyone wants to do it.

although the exact job description is somewhat fluid. Original author’s comment on it is further down.

Lacking release manager, and with release-maker having way too little time, this relied on staff input. Future direction with release manager has been proposed to let them pick up what they can/will do…

Duplicati is extremely volunteer-resource-limited. Your other open source project sounds likely larger.

Duplicati.GUI.TrayIcon.exe, which is what most Windows users probably run (it’s the default), will start multiple instances for multiple users, using different ports, but the trick you require is different versions.

There might be a way to get this more gracefully, but I just do zip file installs to different folders to have numerous test versions available on demand (handy for finding out where a regression first entered…). –server-datafolder keeps the databases from bumping, and I force updates off to avoid update offers… Only oddity I noticed last time I actually had two at once is is web UI confusion if both in same browser.

EDIT:

Downgrading / reverting to a lower version shows how the DB upgrade will probably prevent “go back” to older Beta, but if you mean go back to Beta channel, just change channels and wait for a new Beta. Your wording sounds more like older Beta is the idea. New Beta should have all Experimental features.