Well I personally think we should just ditch 2019.3, and make it 2020.1.
toggle quoted messageShow quoted text
Reason was 2019.3 was betaed basically in christmas, I know users were ready for this, but what is it going to do to the release schedual.
Either we become a release out, or quickly within a few months maybe when windows 20h1 goes golden nvda 2020.1 just to push the numbers up.
In the long term a release out is not a problem except well odd numbers but if it got more than that then users would wander if things were lagging behind.
I realise that this is a major upgrade the last one happened ages ago when we transitioned from the 1.0-2.0 type versions to the year versions.
I know before that we were on build numbers but still.
I would personally not feel cheated if the release of 2019.3 became 2020.1.
Saying that, using a month for a release say 2020.2 or whatever or .1 since its january could mean if you wanted to be incromental you could have many releases but different month numbers, obviously not all the time but still.
On 8/01/2020 4:09 pm, Joseph Lee wrote:
There are two flags to specify compatibility range: minimum API version (the
one Reef is talking about), and last tested version, the upper range I
mentioned briefly. The former signifies the minimum guaranteed NVDA version
an add-on is designed to run on, and is subject to change from NVDA side
based on work that went into a specific release (an add-on author can
specify a specific minimum version). The last tested version flag is used to
tell users the latest NVDA version the author has used to test the add-on.
As long as there is a minimum API version set and the last tested version
covers this API version, add-on is deemed compatible (obviously the true
extent of compatibility cannot be seen until one looks at code and uses
add-ons). However if the compatibility range does not include the current
minimum API version (say, the minimum API is 2020.2 and compatibility range
is between 2018.4 and 2020.1), add-on installation is blocked. The gray area
then is an add-on that claims to cover the minimum API version but turns out
it doesn't even use code optimized for later NVDA releases, or somehow it
doesn't work with the version marked as "last tested version".
In reality, you can change year.major.minor to anything and install an
add-on provided that the minimum API version is covered in the compatibility
range (to test this, I changed year.major to 2020.1 and tried to install an
add-on with minimum and last tested versions set to 2018.4 and 2019.3,
respectively, and NVDA presented typical installation dialog). People are
right in that, at this time of year, calling the upcoming release "2020.1"
is more appropriate (at least to keep with release schedule). At the moment,
however, all the marketing literature (including what's new document, blog
posts and what not) specifies 2019.3, and this was accepted by users. In
reality add-on authors don't have to change compatibility range statements
in their add-on manifests, but once the version is changed, it will create
confusion for users, especially when there is a beta version out there that
users are starting to discover.
Hope this makes sense.
From: firstname.lastname@example.org <email@example.com>
On Behalf Of Luke Davis
Sent: Tuesday, January 7, 2020 6:46 PM
Subject: Re: [nvda-addons] NVDA 2019.3
On Sun, 5 Jan 2020, Reef Turner wrote:
Nikita, to address your concerns. Addons do not need to update theirForgive me for being thick-headed, but doesn't that invalidate the argument
compatibility flags until an API breaking change is introduced into NVDA.
This will not happen every release. When it does happen the
'addonApiVersion.py' will be updated.
made against updating the version number to 2020.1?
The argument that has been posted to the user list and here, has been that
add-on authors would have to update their compatibility flags to 2020.1, and
so all the work done to get manifests ready for 2019.3 would be invalidated.
But if what you said in answer to Nikita's question is true, then that
argument is not particularly valid since add-ons manifested to be compatible
with 2019.3, would still work with 2020.1.
I am obviously missing a piece here.