docs(connectivity_plus): update requirements

[mernen]

Description

This is merely keeping the readme up to date with what was described in the changelog for version 6.0.1.

Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I titled the PR using Conventional Commits.
• I did not modify the CHANGELOG.md nor the plugin version in pubspec.yaml files.
• All existing and new tests are passing.
• The analyzer (flutter analyze) does not report any problems on my PR.

Breaking Change

Does your PR require plugin users to manually update their apps to accommodate your change?

• Yes, this is a breaking change (please indicate that with a ! in the title as explained in Conventional Commits).
• No, this is not a breaking change.

[miquelbeltran]

Thanks!

fyi @vbuberen This is probably already sdk >=3.4.0 since that's required by web. Does it make sense to keep listing these requirements in the README? And, should we bump the min sdk requirement in the pubspec of the plugin to align with web and the README?

[vbuberen]

This is probably already sdk >=3.4.0 since that's required by web

But we are still declaring version range for web from 0.5.0, which didn't need Dart 3.4.0 https://github.com/fluttercommunity/plus_plugins/blob/main/packages/connectivity_plus/connectivity_plus/pubspec.yaml#L44 Or I am missing something here? In any case, I would bump min web to 1.0.0 anyway already and update the requirements afterwards. Suggest to do it in another PR after merging this one.

Does it make sense to keep listing these requirements in the README

I believe it makes sense for convenience of both users and us, maintainers, especially when we need to point the reporter of the issue related to wrong environment, like we regularly have.

[miquelbeltran]

But we are still declaring version range for web from 0.5.0,

Oh, I didn't notice that.

In any case, I would bump min web to 1.0.0 anyway already and update the requirements afterwards. Suggest to do it in another PR after merging this one.

Yep! agree.

I believe it makes sense for convenience of both users and us, maintainers, especially when we need to point the reporter of the issue related to wrong environment, like we regularly have.

All good then!