When is Duplicati expected to come out of beta?

Can’t wait to use it on production :wink:

Well,
it kind of depends. I know many opensource project that run stable for years and still in beta. The longest beta I know of is for video player called xine. I think they reached 1.0 version after 20 years of development.
So if duplicati is developed by old school open source programmer/philosopher , Im afraid Duplicati will never come out of Beta. It is up to you to test the software and decide if Duplicati is stable or not.
Do you think that if Duplicati come out of beta, that it will not have bugs? Sure it will. Beta in Duplicati 2.0.beta only means that you are responsible for sofware you use on your computer, not the maintainer.
People mostly believe in what they read. And sometimes what they read is not representation of reality.
You can read that some code is stable but in practice it is not. Same thing can be other way around.
Again it is up to you to test and decide if something is stable or not.
All we can do, for now, is to say big thanks to people who maintain Duplicati. They read this forum, reply our problems and try really hard to make something good.

1 Like

Well you answered the question ‘is it ready yet’ with ‘never ready’

I asked if I could trust Duplicati to be deployed and not have backups corrupted when you need them.
It is a question towards the developers, of what everyone feels.
imo stability in a backup software is number one, if you fail to recover, no features are worth it…
I tried to deploy restic, but happens that you can’t really deploy it on Windows, you can natively run it, but scheduling it is a nightmare: Windows Task Scheduler runs it and while running displays a black cmd window, can’t really find an alternative (for example Cronical works wonderfully, but it happens that you need to have stuff in very specific path, what I couldn’t figure out).

My biggest hold-out for releasing a stable version was the reported local database corruption issues. This appears to have been fixed with v2.0.5.0.

Prior to this version, my take was that it was “stable” but you could end up in a situation where you had to manually fix some things for it to continue running. The recovery tool is slower but simpler, and I have not heard any reports of actual data loss.

For the question of “when is it ready”, I think we will do a discussion of the possibility of releasing it as stable. I think this discussion can happen in a month or so.

Where and could you include me?

makes me point to an existing discussion, but there’s always a question of how high the bar must be:

Is Duplicati 2 ready for production? is the encouraging (but only) recent update on a very long thread, probably with a variety of different sorts of “production” represented. Is it casual, or bet-the-business? Arguably, bet-the-business should not rely on any single backup, even if it’s a costly commercial one.

Beyond perfect reliability (which can be approached but not achieved), feature requests are limitless, and again, “production” feature needs vary with the production. Everyone, I assume, wants reliability.

is a good point from a long thread in Developer category (are you a developer, or a potential helper?) which tapered off when it became clear that another Beta should be produced first, so there’s 2.0.5.1, which is recent but now providing results from those who have installed it. Uptake is sometimes slow.

Until such time as some other discussion happens, you could consider joining one of those threads…

I’m not a developer, but I write code daily. /shrug
Potential helper in idea development and organization, leading stuff, yes. I have also contributed financially for a year I think.

Deployment, production? Well I like the idea, that Restic backups are verifiable.
Also as for having 2 seperate backup systems on one system I could make the argument on where are you gonna store it. Say Duplicati and Restic. They are both encrypted so they can’t be deduped. Of course on bet-the-business you’d want them on different locations.

I guess the best way would be to ‘fork’ the project every update, Fedora calls this freezing.
Basically no feature updates, unless it’s a very very needy improvement (say makes 5 minutes 10 seconds for at least 30% users) (this shall be defined, what exceptions are allowed) and go on with only bug fixes and so on. Ubuntu LTS is like this as well.
Now how the bug fixes may be implemented is a better question - if you fix a bug in the stable ‘LTS/Frozen’ version, can you also make the same commit/PR to the beta branch (to increase stability for the next stable version) (the next version may change stuff what would make it impossible to make a commit, without writing seperate bug fixes for stable and beta branch)


@Sami_Lehtinen Have you found any alternatives?

What’s best for a large operation like Fedora may be unworkable for a small one that’s stretched…Branching schemes have been discussed in public and in private, but did not attract much interest.

For 2.0.5.1, the normal plan of GitHub master, Canary releases, an Experimental, and a Beta held. Whether or not it can hold after Duplicati hits Stable channel is surely one question for discussion.

There are historically only rare occasions when patch releases go out. It can be done, but it’s work. There is a release manager position open for somebody who would enjoy getting into handling this.

job interview started
what does the release manager include/needs/whatever?

I’m still suspecting it’s very flexible, but some opinions are in:

Canary/Beta Release Logic?

Canary/Beta Release Logic?

Duplicati version numbering

If none of it fits, volunteers in pretty much all areas could help.

Planning, organizing, monitoring, testing, writing, support, etc.

Unknowns in all areas make it tough to give “expected” dates.

IMO