Issues to address to get out of beta

[ts678]

“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: 2.0.4.23 (beta) 2019-07-14:

@ts678

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