Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add-on store: show only devdelopment versions or beta versions of an addon which are higher than the stable version #15801

Closed
Adriani90 opened this issue Nov 17, 2023 · 12 comments
Closed

Add-on store: show only devdelopment versions or beta versions of an addon which are higher than the stable version #15801

Adriani90 opened this issue Nov 17, 2023 · 12 comments

Comments

@Adriani90
Copy link
Collaborator

Is your feature request related to a problem? Please describe.

It is confusing to see beta or development versions of addons that are older than the stable version in the addon store. Moreover, users who accidentally install older beta version of those addons might end up with bugs that have already fixed later on in the stable version.
Examples of addons having older dev versions than stable versions in the addon store are cursor locator or custom notifications (i.e. cursor locator 7.1.0 Beta is older than 9.0 stable or custom notification 1.1.0 Beta is older than 3.0 stable). cc: @nvdaes.

Describe the solution you'd like

Consider only dev or beta versions that are newer than the last stable version of the addon. In case there is no development version newer than the stable version, consider only the stable version and don't show older versions. It might be worthy to consider adding a version history to the context menu of an addon, displaying the releases page on github when opening the menu item.

Describe alternatives you've considered

Leave as is but risk of introducing unwanted bugs when installing older development versions of an addon.

Additional context

None
@CyrilleB79
Copy link
Collaborator

I understand this request and agree with the reason why it has been asked.

Unfortunately, some add-on authors have a versioning scheme that does not allow to order dev or beta versions with respect to stable versions. E.g. Windows Essential stable version (23.11 ) with respect to dev version (20231111.0.0).
There has never been a requirement that versions from various channels could be ordered between two different channels.

@Brian1Gaff
Copy link

Brian1Gaff commented Nov 18, 2023 via email

@XLTechie
Copy link
Collaborator

XLTechie commented Nov 19, 2023 via email

@seanbudd
Copy link
Member

seanbudd commented Nov 21, 2023 •
edited
Loading

Closing this as won't fix - the channel system allows independent version ordering for each channel.
For example:
Stable version 1 comes out for 2023.3, dev version 2 comes out for 2024.1alpha, stable version 3 comes out to fix a bug with 2023.3

@seanbudd seanbudd closed this as not planned Won't fix, can't repro, duplicate, stale Nov 21, 2023
@nvdaes

This comment was marked as off-topic.

Sign in to view
@Adriani90
Copy link
Collaborator Author

@nvdaes I reopen this. Could you please reference the PR that addresses this issue? Thank you very much for taking this into account. Sometimes I get the feeling proposals are getting closed very fast without exchanging arguments or possible solutions for current problems. @seanbudd you say

the channel system allows independent version ordering for each channel.

In my view this causes problems and confuses users. I hear lots of users being overwelmed with some addon versioning schemes especially when communicating with the add-on authors the communication is very inefficient.
If you as NV Access provide an add-on store, you could also set a standard for versioning and add-ons that are registered to this store should follow the versioning scheme. This would improve transparency at least.

@Adriani90 Adriani90 reopened this Dec 4, 2023
@Adriani90
Copy link
Collaborator Author

dev version 2 comes out for 2024.1alpha, stable version 3 comes out to fix a bug with 2023.3

As an user I get really confused. Actually version 3 could be version 1.1 which fixes the bug with 2023.3. This is also how NVDA versioning works. Actually a fix for a bug with 2023.3 which should be rolled out to all users asap is fixed i.e. in 2023.3.1 and not in 2024.1 or so.

@CyrilleB79
Copy link
Collaborator

When the Add-on Store was in development phase as an early prototype, there have been discussions on this topic or related. See issue nvaccess/addon-datastore#407.

I have always found that a common versioning scheme between all channels would be nicer. Versions schemes such as 20230412.0.0 in the dev channel are quite ugly and unusual, and it's not clear if this version embeds features from 2023.11 stable, 2023.12 stable or 2024.01 stable.

Personally, when transitioning from old add-on website/add-on manager to the Add-on Store, I have withdrawn the beta/dev versions for my add-ons, due to the constraints of the versioning scheme and how channel are defined and operated. If I have something to test, I plan just to provide a GitHub release to the add-on mailing list or to specific testers.

Anyway, I have the feeling that add-on authors have found their way with the current constraints of the Store. I'm afraid changing them again won't be popular.

@josephsl
Copy link
Collaborator

josephsl commented Dec 4, 2023

HI,

For Windows App Essentials, dev channel builds are the form yyyymmdd.branch (typically 0).revision. The versioning scheme is intentionally separate from stable and beta channel builds as the add-on uses continuous delivery model for its development and release process.

While we can teach the add-on store to honor version components and channels, how version text gets interpreted is up to humans.

Thanks.

@seanbudd
Copy link
Member

seanbudd commented Dec 5, 2023

Re-closing as won't fix. NV Access will not accept this change to the versioning scheme.
Changing this system like this would invalidate a lot of existing add-on data, causing the needs to remove older versions from the store.

We'd like to improve the add-on manifest in future to:

  • allow for a version string different to the add-on version
  • make the add-on version number well structured into (major, minor, patch, build)
  • make validation more closely match the add-on store
  • add new fields that are included during store submission (licence, channel, publisher, etc)

Unfortunately this would involve a hard breakage of add-ons - i.e. NVDA wouldn't be able to allow overriding compatibility with add-ons using an older manifest schema. We'd like to delay this hard breakage, ideally to align with any potential unavoidable hard breakage in the future (e.g. major python rework, switching to 64 bit, etc).

@seanbudd seanbudd closed this as not planned Won't fix, can't repro, duplicate, stale Dec 5, 2023
@seanbudd
Copy link
Member

seanbudd commented Dec 5, 2023

@Adriani90 @nvdaes - I believe this comment was mistakenly made here. @nvdaes meant to comment on nvaccess/addon-datastore#2111 and was referring to nvaccess/addon-datastore#2115

@seanbudd
Copy link
Member

seanbudd commented Dec 5, 2023

If you as NV Access provide an add-on store, you could also set a standard for versioning and add-ons that are registered to this store should follow the versioning scheme. This would improve transparency at least.

This documentation for this here: https://github.com/nvaccess/addon-datastore/blob/master/docs/submitters/jsonMetadata.md#addonversionnumber

Though I realised we never updated the developerGuide with the suggested conventions for the add-on store. I'll try to look into this soon.
https://www.nvaccess.org/files/nvda/documentation/developerGuide.html#toc36

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@seanbudd @josephsl @XLTechie @nvdaes @Brian1Gaff @CyrilleB79 @Adriani90