Versioning scheme and add-on store


Cyrille
 

Hello

From what I understand of the add-on store, I am a bit concerned by the allowed versions and the possible version scheme, as well as the channels managements.

Before, I used to release dev and stable versions of add-ons such as Outlook Extended, Character Information or Windows Magnifier. With the new terminology of the add-on store, they were actually rather beta versions, i.e. versions targeting early adopters to test new developments. When the dev (beta) version was tested enough, I was updating again the download link in get.php to point to the same stable version for both channels.
Sometimes, the changes I had to do were not so big and I did not want to bother with dev (beta) versions. Thus I was releasing the same .nvda-addon file on the dev and on the stable channel, i.e. I was putting the same link for both channels in get.php of the old addonFiles repo.

With add-on store, it seems to me that I have to make two releases, one for the beta channel and one for the stable channel. Is it correct? If yes, I feel it quite sub-optimal. Or is there another solution?

For now, I have not published beta version again in the new add-on store, waiting to have this clarified on my side. Thus if people are on the dev/beta channel, they remain to a previous version.

Many thanks.
Cheers,

Cyrille


Noelia Ruiz
 

Hi Cyrille, I think you can update the link on the website, for example:
First:
https://www.nvaccess.org/addonStore/legacy?file=characterInformation
https://www.nvaccess.org/addonStore/legacy?file=characterInformation-beta
https://www.nvaccess.org/addonStore/legacy?file=characterInformation-dev

If you don't want to have a link to dev, you can replace the third link
https://www.nvaccess.org/addonStore/legacy?file=characterInformation-dev

See the endpoints in the Design overview document of the addon-datastore.

2023-03-12 23:29 GMT+01:00, Cyrille via groups.io
<cyrille.bougot2@...>:

Hello

From what I understand of the add-on store, I am a bit concerned by the
allowed versions and the possible version scheme, as well as the channels
managements.

Before, I used to release dev and stable versions of add-ons such as Outlook
Extended, Character Information or Windows Magnifier. With the new
terminology of the add-on store, they were actually rather beta versions,
i.e. versions targeting early adopters to test new developments. When the
dev (beta) version was tested enough, I was updating again the download link
in get.php to point to the same stable version for both channels.
Sometimes, the changes I had to do were not so big and I did not want to
bother with dev (beta) versions. Thus I was releasing the same .nvda-addon
file on the dev and on the stable channel, i.e. I was putting the same link
for both channels in get.php of the old addonFiles repo.

With add-on store, it seems to me that I have to make two releases, one for
the beta channel and one for the stable channel. Is it correct? If yes, I
feel it quite sub-optimal. Or is there another solution?

For now, I have not published beta version again in the new add-on store,
waiting to have this clarified on my side. Thus if people are on the
dev/beta channel, they remain to a previous version.

Many thanks.
Cheers,

Cyrille






Sean Budd (NV Access)
 

Hi Cyrille,

With add-on store, it seems to me that I have to make two releases, one for the beta channel and one for the stable channel. Is it correct? If yes, I feel it quite sub-optimal. Or is there another solution?

The solution to that problem in the NVDA add-on store, is that you would not need to make two releases.

The user should always get offered the latest add-on version, compatible with their version of NVDA and channel preference.

If a user is opted into the beta channel, the latest release of the two will be pushed as an update. If a user is not opted into beta, they will get the latest stable.

To be able to maintain a "latest" version for both versions on the legacy endpoint, you will still need to make two releases. This is a limitation of the legacy vs add-on store design.