-
Notifications
You must be signed in to change notification settings - Fork 11
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
suport for flutter sensors v4 #1
base: dieringe
Are you sure you want to change the base?
Conversation
syntax highlight
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We haven't upgraded to Flutter 3.16 yet (we probably will in the coming days though). At that point, I'll try it out to see if it compiles. In the meantime, please use your own fork.
@@ -7,7 +7,7 @@ environment: | |||
sdk: ">=2.12.0 <4.0.0" | |||
|
|||
dependencies: | |||
sensors_plus: ^3.0.3 | |||
sensors_plus: ^4.0.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
4.0.0 was retracted, upgrade to 4.0.1:
https://pub.dev/packages/sensors_plus/changelog
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The caret ^ symbol means the dependency is compatible with all minor and patch releases that do not change the leftmost non-zero digit. So, ^4.0.0 would be compatible with any 4.x.x version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I get that increasing the compatibility range on a package is desirable, but v4.0.0 might still be broken in some circumstances so rather I'd avoid it even in a package
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would definitely recommend always accepting minor and patch releases in any opensource dependency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
However, if you're really afraid that sensors_plus
will release breaking changes in minor/patch versions (which I personally find unlikely); I would recommend at least specifying: 4.0.*
as the constraint
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I definitely agree with the ^, I'm just saying ^4.0.1 is probably better than ^4.0.0, since otherwise 4.0.0 might end up in the dependency resolution of the final project and since that version apparently has build issues in some cases (which was the reason for it being redacted).
I just skimmed through the issue linked in the redaction notice though, so perhaps it's not a big deal after all. In the end it's all just a matter of taste probably.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Åhh, I see what you mean now
Tested it compiled prior to submitting PR. Already using my own fork for 3.16, so this was just as a service to your PR - you can take it or leave it ;) |
@simplenotezy Yes, thanks a lot! Will definitely integrate it I just need to take a look at the dependency choice and mby bump it up. |
No description provided.