I think this is where Duplicati wants to go, and I’ve heard a wish for more frequent betas than current plan.
Perhaps it’s time to think about how to juggle competing objectives:
-
More frequent betas, also avoiding pushes for “one more fix”
Is a sense of upcoming beta good, or a contribution-blocker?
I’m not bold enough to suggest a specific calendar schedule -
Ability to hot-fix betas for things that can’t wait until next beta
Outside disruptions happen, and “test escapes” can as well -
Use usage reporter data to track canary/experimental pickup
A faster beta cycle will mean less time to hope for field tests -
Encourage and develop better-trained volunteers to help test
Ideally they also know how to collect data, and maybe debug
Rare problems seen only in the field are extremely hard to fix -
Simple enough version methods to not confuse contributors
Duplicati can’t train everybody the way a big company might -
A few contributors who know Git well enough to do backports
Probably don’t want to get excessive about parallel branches
Latest beta gets supported, but that might include a backport -
Release numbers that don’t contain unexpected surprises…
I wish 2.0.4.23 came out 2.0.4.5.1, but we’re out of numbers
There was also the idea of third field going up on DB change
I’m wondering when second field will ever go up. Wasted 0?
Leave gaps in number sequence for future use, e.g. 2.0.4.6? -
Document release warnings and oddities as discussed here
DB version info is good, but also say what it means to users
At the moment, it looks like the way three channels emerge from one master is to keep canary open, then lead developer does an experimental as a beta pre-release, then a beta happens. Experimental isn’t open to all changes, as seen here. It’s not clear how open canary is. Huge changes and DB changes might risk preventing an experimental-beta restart-from-canary if that becomes needed. I don’t recall if it’s happened.
This is all part of growing pains. Duplicati is (slowly) becoming higher quality, and to maintain its level while moving forward (can’t afford paralysis from fear of breakages) is the challenge. Is this worth a discussion? Technically it belongs in Developer category but I’ll start here because there’s an experienced VCS person.
Personally, I’ve found that branches and version control can be a headache. Maybe smaller steps are best for a project this size. While there’s a core of regular contributors, there are even more less frequent ones.