Prepare for utf8.encode() to return more precise Uint8List type

[mkustermann]

To avoid analyzer warnings when utf8.encode() will return the more precise Uint8List type, we use const Utf8Encoder().convert() which already returns Uint8List

See dart-lang/sdk#52801

[mkustermann]

After skimming through this (enormously long) wiki page, it's still unclear why this PR would need a version + changelog update (as it's simply changing internals to use an API which avoids an explicit downcast - nothing that would affect/concern an end user).

The packages/image_picker/image_picker_for_web/example isn't even published to pub, it doesn't have version number or changelog. Nothing to do there.

For packages/rfw: Have added a line to CHANGELOG.md & updated pubspec.yaml now.

[stuartmorgan]

After skimming through this (enormously long) wiki page

If you have suggestions for shortening the section I linked to without removing useful information, please let me know.

it's still unclear why this PR would need a version + changelog update

I think the last item in the version exemption list may have been unclear, I've adjusted it. Does that help, or do you still believe the rfw change meets one of the exemption criteria? If so, please let me know which one and why so I can clarify further.

The packages/image_picker/image_picker_for_web/example isn't even published to pub, it doesn't have version number or changelog.

That's not strictly true; packages/image_picker/image_picker_for_web/example/lib/main.dart is prominently displayed on pub.dev. But the specific file you changed isn't published (and the CI is aware of that, so doesn't flag it).

[mkustermann]

I think the last item in the version exemption list may have been unclear, I've adjusted it. Does that help, or do you still believe the rfw change meets one of the exemption criteria? If so, please let me know which one and why so I can clarify further.

I think of the change in itself falls into a category of changes that a) are not urgent to get published b) have no real user-visible effect. Other things that may fall into this category may be e.g. tiny perf/memory improvements, better code quality, formatting of code, smaller refactoring, ... None of those are very urgent to be published as they have little user impact, also users may have no interest in knowing about them (good to keep high signal-to-noise ratio in CHANGELOG).

That being said: The reason for the PR is a related change to Dart SDK's utf8.decode() which will make this package have analyzer flags. So maybe that justifies increasing the number / getting it published soon.

But the specific file you changed isn't published (and the CI is aware of that, so doesn't flag it).

Our dart-flutter CI does flag that as an analyzer error when doing the Dart SDK change to utf8.decode(). See this build failure:

Running command: "dart analyze --fatal-infos" in /b/s/w/ir/x/t/flutter_packages.XGEKCL/packages/image_picker/image_picker_for_web
Analyzing image_picker_for_web...

   info - example/integration_test/image_picker_for_web_test.dart:16:25 - Unnecessary cast. Try removing the cast. - unnecessary_cast
   info - example/integration_test/image_picker_for_web_test.dart:17:30 - Unnecessary cast. Try removing the cast. - unnecessary_cast

If you have suggestions for shortening the section I linked to without removing useful information, please let me know.

My preference would be to lean on as little process as possible (lowering the barrier for contributors) e.g.:

• Update CHANGELOG.md if users of the package may have an interest in knowing what the PR changes (e.g. breaking change, new apis, larger perf/memory improvements, bug fixes, ...)
• Update pubspec.yaml' major, minor and patch according to semantic version standard. If the change should be published soon, ensure to update the semver in the PR - otherwise it's ok to keep existing version (i.e. future PRs that increase version (and cause publish of package) will include the change)

@stuartmorgan Is there anything I should change before the PR can be approved?

[stuartmorgan]

I think the last item in the version exemption list may have been unclear, I've adjusted it. Does that help, or do you still believe the rfw change meets one of the exemption criteria? If so, please let me know which one and why so I can clarify further.

I think of the change in itself falls into a category of changes that a) are not urgent to get published b) have no real user-visible effect. Other things that may fall into this category may be e.g. tiny perf/memory improvements, better code quality, formatting of code, smaller refactoring, ... None of those are very urgent to be published as they have little user impact, also users may have no interest in knowing about them (good to keep high signal-to-noise ratio in CHANGELOG).

I think you're answering a different question than I asked; it seems like you are arguing why you personally wouldn't version it if the policy were to leave it to everyone's individual judgement, I'm asking what part of the documentation (if any) is still unclear that it isn't exempt according to our actual policy.

But the specific file you changed isn't published (and the CI is aware of that, so doesn't flag it).

Our dart-flutter CI does flag that as an analyzer error when doing the Dart SDK change to utf8.decode()

I'm talking about the CI check that was failing when you were missing a version bump for rfw, where you were changing production code, not the analyzer:
https://cirrus-ci.com/task/5195956182843392

The CI was correctly only flagging that rfw needed a version and changelog change.

If you have suggestions for shortening the section I linked to without removing useful information, please let me know.

My preference would be to lean on as little process as possible (lowering the barrier for contributors) e.g.:

• Update CHANGELOG.md if users of the package may have an interest in knowing what the PR changes (e.g. breaking change, new apis, larger perf/memory improvements, bug fixes, ...)
• Update pubspec.yaml' major, minor and patch according to semantic version standard. If the change should be published soon, ensure to update the semver in the PR - otherwise it's ok to keep existing version (i.e. future PRs that increase version (and cause publish of package) will include the change)

That's not shortening the section without removing information, that's rewriting the policy.

The reason that we have the policy that's written there now is because when we had a policy like the one you are describing, it had worse outcomes and more manual overhead.

@stuartmorgan Is there anything I should change before the PR can be approved?

It already was approved (and is now passing CI). Were you looking for additional review?

[ditman]

Thanks for the cleanup!

[mkustermann]

@ditman Thanks for approving & merging!