Add-on Updater June 6th try build posted, getting ready for wider testing, initial version of JSON file is complete


 

Hi all,

As I kept thinking about latest happenings with Add-on Updater and JSON proposal, I can’t help but think that I haven’t felt this energy since August 2018 when Add-on Updater was born.

Add-on Updater June 6th try build is now available:

https://github.com/josephsl/addonUpdater/releases/download/21.05.1/addonUpdater-20210606-dev.nvda-addon

 

Changes:

  • If using development builds of add-ons, update checks will occur regardless of NVDA release. The whole point of development builds is to let users test things and send feedback to developers. As such, I do not recommend using it in production environments unless directed to do so for testing reasons.

 

JSON file updates:

  • Initial version is complete (see an earlier message about JSON file link). As of June 6th, the JSON file records stable add-ons found on community add-ons website under “active” key, and legacy add-ons are recorded in “legacy” key. Note that the schema can change – please do comment on things that can be added/removed/improved.
  • As you parse the JSON file, you may notice that add-ons are listed in alphabetical order. This was done for efficiency and readability (it is faster to do binary searches if things are sorted already). Although this looks okay for now, I’m sure some members might ask that add-ons be sorted based on registration/legacy declaration date to denote history of add-ons and the community (doing that will require analyzing translations workflow Subversion commits).
  • I’m interested in feedback from NV Access people because I think the organization is best positioned to manage the JSON infrastructure with input from add-on authors and community members.

 

Note on add-on testing: June 6th try build should be a bit more stable, although I expect rough edges. Also, this try build will be made available to some users and members of NVDA Development list for further testing and to gather feedback on the JSON infrastructure from other contributors. Lastly, as I announced recently, Add-on Updater try builds must be applied manually, and this is intentional.

 

Thanks.

Cheers,

Joseph


Noelia Ruiz
 

Hello, imo, NV Access should provide feedback, but the main attention
should be paid to the add-on store, at least to the framework to test
it until it can be implemented inside NVDA.
I think there are lots of add-ons floating, updated or not by authors,
and it's good to use sha256 to identify if two add-ons with the same
name are or not the same, and of course providing the ability to
search them from NVDA may encourage people to send them to the store.
But if this may serve as a proof of concept of the store, for me is OK
and NV Access can provide advice on this.
You may wantto check our nvdaes/validateNvdaAddonMetadata to use it:

https://github.com/nvdaes/validateNvdaAddonMetadata/

This was created in response to
https://github.com/nvdaes/validateNvdaAddonMetadata/

Available as a PR in the store submission repo at

https://github.com/nvaccess/addon-store-submission/pull/8

2021-06-06 4:19 GMT+02:00, Joseph Lee <joseph.lee22590@gmail.com>:

Hi all,

As I kept thinking about latest happenings with Add-on Updater and JSON
proposal, I can't help but think that I haven't felt this energy since
August 2018 when Add-on Updater was born.

Add-on Updater June 6th try build is now available:

https://github.com/josephsl/addonUpdater/releases/download/21.05.1/addonUpda
ter-20210606-dev.nvda-addon



Changes:

* If using development builds of add-ons, update checks will occur
regardless of NVDA release. The whole point of development builds is to let
users test things and send feedback to developers. As such, I do not
recommend using it in production environments unless directed to do so for
testing reasons.



JSON file updates:

* Initial version is complete (see an earlier message about JSON file
link). As of June 6th, the JSON file records stable add-ons found on
community add-ons website under "active" key, and legacy add-ons are
recorded in "legacy" key. Note that the schema can change - please do
comment on things that can be added/removed/improved.
* As you parse the JSON file, you may notice that add-ons are listed
in alphabetical order. This was done for efficiency and readability (it is
faster to do binary searches if things are sorted already). Although this
looks okay for now, I'm sure some members might ask that add-ons be sorted
based on registration/legacy declaration date to denote history of add-ons
and the community (doing that will require analyzing translations workflow
Subversion commits).
* I'm interested in feedback from NV Access people because I think the
organization is best positioned to manage the JSON infrastructure with
input
from add-on authors and community members.



Note on add-on testing: June 6th try build should be a bit more stable,
although I expect rough edges. Also, this try build will be made available
to some users and members of NVDA Development list for further testing and
to gather feedback on the JSON infrastructure from other contributors.
Lastly, as I announced recently, Add-on Updater try builds must be applied
manually, and this is intentional.



Thanks.

Cheers,

Joseph







 

Hi,
Indeed, I consider the JSON file proposal a stepping stone toward add-ons store research.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Noelia Ruiz
Sent: Saturday, June 5, 2021 8:51 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Add-on Updater June 6th try build posted, getting ready for wider testing, initial version of JSON file is complete

Hello, imo, NV Access should provide feedback, but the main attention should be paid to the add-on store, at least to the framework to test it until it can be implemented inside NVDA.
I think there are lots of add-ons floating, updated or not by authors, and it's good to use sha256 to identify if two add-ons with the same name are or not the same, and of course providing the ability to search them from NVDA may encourage people to send them to the store.
But if this may serve as a proof of concept of the store, for me is OK and NV Access can provide advice on this.
You may wantto check our nvdaes/validateNvdaAddonMetadata to use it:

https://github.com/nvdaes/validateNvdaAddonMetadata/

This was created in response to
https://github.com/nvdaes/validateNvdaAddonMetadata/

Available as a PR in the store submission repo at

https://github.com/nvaccess/addon-store-submission/pull/8

2021-06-06 4:19 GMT+02:00, Joseph Lee <joseph.lee22590@gmail.com>:
Hi all,

As I kept thinking about latest happenings with Add-on Updater and
JSON proposal, I can't help but think that I haven't felt this energy
since August 2018 when Add-on Updater was born.

Add-on Updater June 6th try build is now available:

https://github.com/josephsl/addonUpdater/releases/download/21.05.1/add
onUpda
ter-20210606-dev.nvda-addon



Changes:

* If using development builds of add-ons, update checks will occur
regardless of NVDA release. The whole point of development builds is
to let users test things and send feedback to developers. As such, I
do not recommend using it in production environments unless directed
to do so for testing reasons.



JSON file updates:

* Initial version is complete (see an earlier message about JSON file
link). As of June 6th, the JSON file records stable add-ons found on
community add-ons website under "active" key, and legacy add-ons are
recorded in "legacy" key. Note that the schema can change - please do
comment on things that can be added/removed/improved.
* As you parse the JSON file, you may notice that add-ons are listed
in alphabetical order. This was done for efficiency and readability
(it is faster to do binary searches if things are sorted already).
Although this looks okay for now, I'm sure some members might ask that
add-ons be sorted based on registration/legacy declaration date to
denote history of add-ons and the community (doing that will require
analyzing translations workflow Subversion commits).
* I'm interested in feedback from NV Access people because I think the
organization is best positioned to manage the JSON infrastructure with
input from add-on authors and community members.



Note on add-on testing: June 6th try build should be a bit more
stable, although I expect rough edges. Also, this try build will be
made available to some users and members of NVDA Development list for
further testing and to gather feedback on the JSON infrastructure from other contributors.
Lastly, as I announced recently, Add-on Updater try builds must be
applied manually, and this is intentional.



Thanks.

Cheers,

Joseph