I’m not sure that’s what he was saying if you’re talking about
it seemed like agreement with your proposal, quoted above that. I’ll continue, based on that assumption.
This discussion is at various levels, but there are similarities. For example, if we say damage to backup destination is a big issue, and damage to database is a smaller issue (because backup destination can usually recreate DB), then we can apply same idea to any release variety, e.g. regarding regressions or newfound fixes. Sometimes a big issue simply has no fix available yet, although seeing it on a list might make people focus more – and one doesn’t need to be a coder to help the coders find good test cases.
To decide when to release something, can we look at what’s fixed-but-not-shipped versus desired-fixes? Big-issue fixes after v2.0.4.5-2.0.4.5_beta_2018-11-28 and v2.0.4.22-2.0.4.22_canary_2019-06-30 exist. Discussion is possible (I can nominate some), or we could put them on milestone as already closed so amount of closed issues can be weighed against not-yet-closed when weighing the decision to release.
My nominations for things worth squeezing into next canary, which is probably the path to the next beta:
CheckingErrorsForIssue1400 and FoundIssue1400Error test case, analysis, and proposal #3868 is the database-breaker I’d propose we ensure makes next beta (which may mean catching the next canary).
The somewhat obscure backup-breaker is that FluentFTP needs upgrading. Problems after upgrade to 2.0.4.21 describes how parallel uploads code change tickled a bug (now maybe fixed) in the aftp library.
Update framework to 462 #3844 is needed to update FluentFTP, then someone needs to actually test it.
EDIT: In the forum post, you can see how this regression was a big beta issue once, so let’s get it fixed.