Support min_os_version on Windows#2855
Conversation
| app_packages_path: Path, | ||
| **kwargs, | ||
| ): | ||
| support_min_version = 10240 # Windows 10 |
There was a problem hiding this comment.
Hardcoded because there's no reliable way to detect the minimum version from the support package as far as I know.
There was a problem hiding this comment.
The support package won't include this information, but we could include it in the briefcase.toml in the app template - that is where the support package build number is defined, so it would make sense to tie the two together, rather than hard-coding the value here. If it isn't in the template, falling back to "not defined" would make sense to me.
freakboy3742
left a comment
There was a problem hiding this comment.
Thanks for the update. This looks like a really useful improvement; a couple of suggestions inline regarding how this will be applied in practice.
| app_packages_path: Path, | ||
| **kwargs, | ||
| ): | ||
| support_min_version = 10240 # Windows 10 |
There was a problem hiding this comment.
The support package won't include this information, but we could include it in the briefcase.toml in the app template - that is where the support package build number is defined, so it would make sense to tie the two together, rather than hard-coding the value here. If it isn't in the template, falling back to "not defined" would make sense to me.
| "Your Windows app specifies a minimum build number of " | ||
| f"{min_version}, but the support package only supports " | ||
| f"{support_min_version}" | ||
| ) |
There was a problem hiding this comment.
This checks the value on the installer side, but it won't put the value into the template in the "default" case. i.e., it will catch the error if I try to build the app on Windows 8, but if I build the app on Windows 11, and then try to install on Windows 8, it won't pass that information down unless I explicitly put min_os_version in the app config.
freakboy3742
left a comment
There was a problem hiding this comment.
Looking good; a couple of edge cases and style notes inline.
| ], | ||
| ) | ||
| def test_min_os_version( | ||
| create_command, first_app_templated, template_version, app_version, compatible |
There was a problem hiding this comment.
As a style thing, if a list of arguments long enough that it's triggering ruff's "put it on another line" rule, we go straight to the "one argument per line" formatting (which you get out of ruff automatically by adding a comma to the end of the last argument).
| if template_min_version: | ||
| min_version = getattr(app, "min_os_version", None) | ||
| if min_version is None: | ||
| app.min_os_version = template_min_version |
There was a problem hiding this comment.
If this is going to propagate into the template, it can't be done here.
install_app_requirements is invoked after the app template is generated, so with this approach, the min_os_version would only be annotated onto the app (a) after the template has been rolled out, and (b) only if requirements were being installed (which they should always be if you're creating the template, but it also means updating requirements would cause the app to be annotated).
If the app configuration is being updated, it should be done in a finalize_app_config() override so that every app configuration has a min_os_version under Windows.
There was a problem hiding this comment.
But we can't read briefcase.toml in finalize_app_config() as it's not available at that stage?
Will setting a default min_os_version in cookiecutter.json work (same value as target_windows_build)?
There was a problem hiding this comment.
But we can't read briefcase.toml in finalize_app_config() as it's not available at that stage?
Hrm - good point...
Will setting a default min_os_version in cookiecutter.json work (same value as target_windows_build)?
I guess that works - it's also the same approach that the iOS and macOS templates use, so there's at least some consistency there.
The value in briefcase.toml is still needed because the support package can't report a minimum version - but the value can be templated from {{ cookiecutter.min_os_version }} to avoid duplication.
There was a problem hiding this comment.
but the value can be templated from {{ cookiecutter.min_os_version }} to avoid duplication.
This will break the build-time check though: target_windows_build will always match min_os_version.
| template_min_version = self.target_windows_build(app) | ||
| if template_min_version: |
There was a problem hiding this comment.
| template_min_version = self.target_windows_build(app) | |
| if template_min_version: | |
| if template_min_version := self.target_windows_build(app): |
| min_version = template_min_version | ||
| if min_version and int(min_version) < template_min_version: |
There was a problem hiding this comment.
Isn't this an elif? Also - is the int conversion required?
| min_version = template_min_version | |
| if min_version and int(min_version) < template_min_version: | |
| elif min_version < template_min_version: |
There was a problem hiding this comment.
I was thinking it should a string (e.g min_os_version = "17763") for consistency with other platforms, but that's probably unnecessary here.
There was a problem hiding this comment.
Hrm - I guess that's fair. I guess it doesn't hurt to have the extra safety there.
This adds support for specifying the minimum supported Windows build number using the
min_os_versionoption.PR Checklist:
Context
ankitects/anki#4765