toggle quoted messageShow quoted text
You are reflecting interesting arguments. Anyway, I thing that this should be chosen by author in a case basis. Fon example, if they can avoid bugs before releasing an add-on under developmento or know them and dont need that people suffer these bugs, they can do it before. And in other cases, according with your arguments, authors can ommit the last tested version flag in add-ons under development or pre-released to be tested in alpha or beta versions of NVDA. Then, I think that the current flag is correctly designed, since it is not mandatory and, if it is not present, it will not enforze incompatibility and this can help to detect errors.
Enviado desde mi iPhone
El 3 oct 2019, a las 16:29, derek riemer <driemer.riemer@...
On Wed, Oct 2, 2019 at 11:33 PM Noelia Ruiz <nrm1977@...
Hi, really, imo they shouldn't be exempt, since this could break things
in the system like crashes
If you're signing up to test beta and alpha software, the expectation is that there will be crashes. I'd much rather a developer discover that their addon isn't compatible, or is crashing NVDA, so the flags can be updated, and make the ease of developing their addon maximally easy on developer editions, because these editions are designed to surface errors before they reach the general public. On developer editions, for example, addon authors get error sounds, which allow them to detect problems in the addon. I could be easily persuaded to allow the minimNVDAVersion flag to be honored in developer editions, for sure, but I'd rather not torture developers with untested addons warnings on developer editions of their screen reader. The number of testers of NVDA alpha snapshots is below 2% and eating into that number is extremely likely to lead to more bugs in stable NVDA versions. Every single tester of alpha is important, so we catch bugs before the beta editions and can iterate early in the design. Catching bugs in beta is also important, and the number of beta testters is slightly higher even in beta. If addons break, or are found to break in an alpha or beta version, that often can give the developer of such addons weeks or months of time to fix the addon before it hits the api incompatible version, leading to a better experience for the whole product.