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.

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

NVDA 2024.1: switch to requiring 2024.1 or later #163

Open
josephsl opened this issue Dec 30, 2023 · 4 comments
Open

NVDA 2024.1: switch to requiring 2024.1 or later #163

josephsl opened this issue Dec 30, 2023 · 4 comments

Comments

@josephsl
Copy link
Collaborator

Hi,

The following builds on #161:

Now that main branch supports NVDA 2024.1 changes, I propose moving to requring NVDA 2024.1 in a future ad-on release. This wil mean strictly using Python 3.11 syntax, speech on demand syntax in 2024.1, among others.

To give time for folks to migrate to the future release, I propose the following process:

  1. Release 2024.1 compatibility version: as soon as NVDA 2024.1 RC is released.
  2. Release a dev/beta channel build with 2024.1 requirement active: a few weeks after step 1.
  3. Release one or two stable channels supporting 2023.x (in case folks report bugs).
  4. Release 2024.1 requirement build to the stable channel: a month or two after step 3.

I will create two pull requests:

  1. Python 3.11 syntax: assignment expressions, type unions, structural pattern matching (with enums if needed)
  2. NVDA 2024.1 API: speech on demand keyword in script decorator

I will submit these pull requests shortly after 2024.1 compatibility version is released (after step 1). In preparation for these, I will deal with some type hinting issues such as proper typing information for NVDA object, mostly to replace typing.Any usage with proper NVDA object type hint to make the code more readable.

Thanks.

@josephsl
Copy link
Collaborator Author

Hi,

Actually, typing.Any -> NVDAObject conversion will be deferred until Python 3.11 pull request is merged.

Thanks.

@ChrisDuffley
Copy link
Owner

ChrisDuffley commented Dec 30, 2023

To give time for folks to migrate to the future release, I propose the following process:

  1. Release 2024.1 compatibility version: as soon as NVDA 2024.1 RC is released.
  2. Release a dev/beta channel build with 2024.1 requirement active: a few weeks after step 1.
  3. Release one or two stable channels supporting 2023.x (in case folks report bugs).
  4. Release 2024.1 requirement build to the stable channel: a month or two after step 3.

I'd propose until the next stable rlease of 2024, but wasn't sure what your thoughts were on that? The reason for this is some may have add-ons that are not yet compatible with 2024 even a few weeks or months after the first stable. I'd hope this year's transition will be a better one than previous years, but wanted to keep that in mind. Of course, right now it's set to 2022.4 as the minimum required version, but I can change it to 2023.1 since that's the earliest I've technically tested (really 2023.3). I can address this in the Readme once I release the Stable build.
Thanks!

@josephsl
Copy link
Collaborator Author

josephsl commented Dec 30, 2023 via email

@josephsl
Copy link
Collaborator Author

Hi,

For minimum NVDA version, I think we can change it once we do move to requiring NVDA 2024.1 or later.

Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants