Re: Idea: Multiple versions of NVDA


Brian's Mail list account
 

Yes there really is nobody standing at your back to be totally up todate at all times. As I have mentioned before. Having to use older versions of software and operating systems is sometimes required to do the job. This is life, so unless you or the company has bottomless pockets things can get quite complicated at times.

Getting back on topic for nvda though, I think the compromise of keeping the version that does what you want is fine, and then having an alternative newer or older one as a portable works well, there do seem to be fewer places where a portable version cannot work than at any time in the past. I have each on a shortcut on the desktop which drives a batch file that closes any running version then opens the target on.
Brian

--
bglists@...
Sent via blueyonder.(Virgin media)
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.

----- Original Message -----
From: "Joseph Lee" <joseph.lee22590@...>
To: <nvda@nvda.groups.io>
Sent: Monday, September 26, 2022 3:27 AM
Subject: Re: [nvda] Idea: Multiple versions of NVDA


Hi,

This is an interesting idea. However, I'm afraid this cannot be done due to technical and distribution reasons:

* Technical: in some parts of NVDA (notably when installing it), NVDA will insist on using a dedicated folder inside program files (or program files (x86)) folder for installation files. This is also needed when upgrading as the update routine for the installed version will look for an installed copy of NVDA to determine if the installed version is older than the update (checks the timestamp for the NVDA executable file). While using multiple installation folders would work for stable releases, it doesn't work on alpha builds as they do not have easily discernable year.major.minor text on the surface (you must look at file metadata to obtain this information).
* Distribution: somewhat tied to technical reason, you can in fact install NVDA from Microsoft Store (a limited version exists) as well as through Windows Package Manager (winget). In order for these distribution channels to work, they need to know where NVDA is stored, and they prefer a single copy of a software product such as NVDA to be installed (as recorded in Windows Registry and elsewhere). If we have multiple installed versions of NVDA, Winget will get confused (about version and installation directory) when you tell it to upgrade NVDA.

I think there is another reason that's sometimes overlooked: the way NV Access and Vispero communicates about version information are not really compatible with each other's understanding of what a major version is. Vispero uses major.0 or year (depending on who you ask) to denote major JAWS releases, whereas NV Access denotes year.major as simply that: major releases throughout a given year. Therefore 2022.1 and 2022.2 are not revisions of NVDA 2022, but denotes first and second major releases of the calendar year 2022; 2022.2.3, on the other hand, is truly a revision of 2022.2. So the upcoming 2022.3 release is not another revision of NVDA 2022, but rather the third major release of the year 2022. This is why even between these year.major releases, things can change, sometimes affecting add-on development plans (this is why I announced here a few weeks ago that my add-ons require NVDA 2022.2, as the second major release of the year 2022 had changes that affected at least Windows App Essentials due to the fact that some major features from the add-on were included in that NVDA release).

As for NV Access making compatibility breaking releases every year: I have asked NV Access to provide justifications so they won't have to break add-ons every year. Part of the mess that was 2022.1 was caused by last-minute reversion of a massive breaking change that affected many add-ons, some of them no longer maintained (and even some we lost contact with maintainers for some time). Even with that reversion, it did affect speech synthesizers due to a change to speech processing internals that synthesizers may have been relying on. The good news is that NV Access is more proactive on add-ons, even creating a dedicated announcement mailing list to communicate breaking changes (Quentin would know more about this than I do).

I think there are two important issues that should be addressed at some point:

1. Clarifying year.major: as NV Access noted many times and I have explained above, in NVDA world, NVDA 2022.2 is not NVDA version 2022 update 2; it is year 2022, NVDA major release 2. I think part of the confusion stems from the fact that we see add-ons community become more active around year.1 beta release to start addressing compatibility breaking changes, being translated to users as though NVDA 2022 is on its way when in fact IT IS NOT REALLY THAT (see above as to why); it happens to be a major release for which NV Access has targeted for moving to new ways of doing things.
2. Communication: this is perhaps the biggest issue to address: discussions between NV Access, contributors, and add-on authors. At least NV Access is learning from 2022.1 experience and has created a way to talk to add-on authors about upcoming breaking changes via an announcement list. The question now is how will add-on authors respond when 2023.1 development takes off (foundation is being laid at the moment inside NVDA source code, and if I'm reading recent GitHub discussions correctly, 2023.1 will be a massive (and I think, necessary) compatibility breaking release (won't talk about it here as things can change without notice)).

So, in summary, while this is an attractive idea, I think practicality beats purity (directly quoting Zen of Python): ideas are good, but we also need to think about practices and limitations.

Hope this answers many questions.

Cheers,

Joseph

Join {nvda@nvda.groups.io to automatically receive all group messages.