-
Notifications
You must be signed in to change notification settings - Fork 649
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
update win32 #1281
update win32 #1281
Conversation
Hi @frg2089, I understand your request to update win32 to the latest major version 5.0.0. However, generally speaking, it is highly-dangerous to specify the version of a dependency in such a loose manner, e.g.
see https://semver.org/. I cannot merge your changes to pubspec.yaml since
My suggestion: we pin the version of win32 to |
@miguelpruivo: last time when we bumped win32 from v3 to v4, we released a new patch version of The only difference: this time, I had to upgrade my Flutter installation from from 3.7.12 to 3.10.1 because initially I got this error when I updated win32 to v5:
I don't fully comprehend the implications of this Flutter upgrade. Originally, I thought that I would have to change the line in environment:
sdk: ">=2.17.0 <3.0.0" However, it turned out that upgrading Flutter to the latest version was already sufficient. If you're fine with bumping the patch version of |
FYI, this is not correct. There is nothing dangerous about expressing what is actually required of a dependency. It would be dangerous to do that if those versions were untested. If, however, something was written against version X.0.0 of a package, and compiles and works without changes with version X+1.0.0, then a range spanning two major versions accurately expresses the version requirements.
If the package works correctly, that's not an issue. It is in fact a feature, since it increases compatibility with other packages (e.g., those that haven't been updated to the latest major version of the dependency).
The existence of breaking changes somewhere in an API surface does not mean that all usage of any part of that API surface will be broken. A simple example is a major version change that does nothing but remove deprecated API. Clients that have already stopped using the API when it was originally deprecated are completely unaffected by the change. |
Thanks @stuartmorgan , I learned something new :) From your import 'package:win32/winrt.dart'; to import 'package:win32/win32.dart'; Therefore, I thought that we could not have put a lose version constraint such as |
@stuartmorgan if the comment from @philenius is correct, are you able to get package path_provider updated as the change made in flutter/flutter#127289 has blocked the latest version of this package from being used |
I'm not following your comment, sorry. No change has been made in that issue, and no change to |
path_provider has a fixed dependency on win32 that prohibits later releases of win32, which is now blocking later releases of other packages that are depending on later releases of win32 fixes. Seems odd that path_provider can't use any version greater than v5.0.x which would have allowed file_picker and others to be updated. |
Sorry. I just now found the PR and as you didn't respond to the comment earlier I incorrectly assumed no action was taken |
Please re-read my comment. I understand the dependency conflict. What I don't understand, as I said there, is your attribution of that conflict to a change in
I assume you mean greater than 4.x. I'm not sure what you find odd about |
it may worked on win32: '>=3.0.0 <6.0.0'.
close #1280