Skip to content

Bump API version for 2024.1#15367

Merged
seanbudd merged 1 commit into
masterfrom
bumpAPIVersion
Sep 8, 2023
Merged

Bump API version for 2024.1#15367
seanbudd merged 1 commit into
masterfrom
bumpAPIVersion

Conversation

@seanbudd

@seanbudd seanbudd commented Sep 5, 2023

Copy link
Copy Markdown
Member

No description provided.

@CyrilleB79

Copy link
Copy Markdown
Contributor

@seanbudd or @michaelDCurran:
This PR has been merged early in the alpha cycle.

Currently, some add-ons are setting 2024.1 as their last tested version.
Since these add-on want to maintain only stable channels we end up with stable add-ons compatible with 2024.1 (Say product name and version, Resource monitor). With the changes that are still expected for 2024.1 (Python upgrade, wxPython upgrade, etc.), there is a non-zero probability that something break in these add-ons.

Was it a mistake to update API version so early? I have the feeling that such behaviour was not anticipated nor expected.

Thanks.

@nvdaes

nvdaes commented Sep 21, 2023 via email

Copy link
Copy Markdown
Collaborator

@LeonarddeR

Copy link
Copy Markdown
Collaborator

I think @CyrilleB79 raises a valid point here that might best be discussed in https://github.com/nvaccess/addon-datastore-validation

In short, I think that an API or last tested version of 2024.1 should be denied for stable and beta add-ons and only accepted for dev add-ons. As soon as there's a 2024.1 beta, beta add-ons could be accepted but stable add-ons should still be denied until a stable version of that NVDA release is available. This is at least how I handle compatibility with my add-ons.

@XLTechie

XLTechie commented Sep 21, 2023 via email

Copy link
Copy Markdown
Collaborator

@CyrilleB79

Copy link
Copy Markdown
Contributor

In short, I think that an API or last tested version of 2024.1 should be denied for stable and beta add-ons and only accepted for dev add-ons.

I do not know if this can be enforced by NVDA, but it should at least be clarified if it is recommended as a good practice or even as a requirement to be followed by add-on authors.
This clarification may be done in File metadata and controls, but maybe there are other places where this should also be added.

@nvdaes

nvdaes commented Sep 21, 2023 via email

Copy link
Copy Markdown
Collaborator

@seanbudd

seanbudd commented Sep 21, 2023

Copy link
Copy Markdown
Member Author

Please create new issues rather than discussion on closed PRs.

We cannot really stop add-on authors from releasing stable channel add-ons which falsely claim compatibility with an unstable version of NVDA. They are making this decision at their own risk, and it will cause users trouble in the future, if they try and install these add-on versions with a future stable version of NVDA.

We have been fairly clear in the:

I am not sure what else we can do here other than removing add-ons and rejecting approval for submitters who falsely claim compatibility in stable channel add-ons.

@nvaccess nvaccess locked as off-topic and limited conversation to collaborators Sep 21, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants