Stable version instead of beta?

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.