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

suport for flutter sensors v4 #1

Open
wants to merge 2 commits into
base: dieringe
Choose a base branch
from

Conversation

simplenotezy
Copy link

No description provided.

Mattias Siø Fjellvang and others added 2 commits November 30, 2023 13:46
Copy link
Member

@ciriousjoker ciriousjoker left a 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
Copy link
Member

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

Copy link
Author

@simplenotezy simplenotezy Dec 3, 2023

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

Copy link
Member

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

Copy link
Author

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.

Copy link
Author

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

Copy link
Member

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.

Copy link
Author

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

@simplenotezy
Copy link
Author

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 ;)

@ciriousjoker
Copy link
Member

@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.

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

Successfully merging this pull request may close these issues.

2 participants