Closed mbfakourii closed 1 year ago
Patch and project coverage have no change.
Comparison is base (
aefc84e
) 39.33% compared to head (5145c8c
) 39.33%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Looks good, could you write a PR title that describes the issue (not the solution)
I have no other idea, only dio was updated, the reason was a bug in the dio package
Why do we have to update the dio package, if we are using a range operator anyway?
- dio: ^5.2.0+1
+ dio: ^5.3.2
If I understand this correctly, ^5.2.0+1
will use the latest dio version <6.0.0 as soon as a newer version is released, right?
Why do we have to update the dio package, if we are using a range operator anyway?
- dio: ^5.2.0+1 + dio: ^5.3.2
If I understand this correctly,
^5.2.0+1
will use the latest dio version <6.0.0 as soon as a newer version is released, right?
Because of these issues, we have to give a new version quickly, and the current version cannot be used.
I checked the dio
package and did not see anything from version 6
But why do we have to update our package? In my understanding, the Parse Flutter SDK will always install the latest release of dio >= 5.2.0 < 6
, because the dependency is ^5.2.0+1
. So even if we don't update the package, Parse Flutter SDK should already use 5.3.2
, not 5.2.0
. I thought that was the whole point of Dart/Flutter forcing people to use version ranges and not allowing a lock file to be uploaded to the registry, or am I missing something?
I think not only do we not have to release a new version, we also don't have to update any dependency manually unless it's a major version increment. The only reason to upgrade a dependency without being a major version increment is if the Parse Flutter SDK requires a higher minimum version because it uses a certain feature for example that is not available in a lower version. But if it's just a bug fix in the dependency, then we shouldn't have to care, that's what the version range is for.
Yes, I think the problem was solved with Revert on the dio side! I am waiting for the answer of those who have problems
I think we should see this also in our CI. In fact the CI previously failed and now passes. In my opinion this PR can be closed, as well as the related issue, because it was a dio issue, not a Parse issue.
I think we should see this also in our CI. In fact the CI previously failed and now passes. In my opinion this PR can be closed, as well as the related issue, because it was a dio issue, not a Parse issue.
sure
Pull Request
Issue
Closes: #958
Approach
Update dio to
dio: ^5.3.2
Tasks