chore(package_info_plus): support web 0.5.0

[Leptopoda]

Description

Allow the latest 0.5.0 release of the web package.
Other packages like http already require a minimum version of 0.5.0 (changelog)[https://pub.dev/packages/http/changelog#121].

Related Issues

none

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. (issues are already present on main)

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.

[vbuberen]

Thanks for your contribution. This is quite a drastic change and this is also a breaking change. I wouldn't like to do such bump for min Flutter and web package unless there is a strong reason for that. Would you mind to provide any explanations for this bump and why widening the existing range to include 0.5.0 won't satisfy your needs?

[Leptopoda]

Hi and thank you for the fast reply.
Could you please explain me how this is going to be breaking?
Projects that don't yet support the flutter or web version in question (3.19 and 0.5 respectively) just would not get the update so nothing is breaking? Even when they do the update the api of the package didn't change so again no code would break.
Have a look at the http package from the dart team that did a similar change with a patch version bump.

There are multiple reasons as to why we want to move to move to web 0.5.
One is not wanting to fall behind on a package that evolves quite fast.
Another is that web 0.5 re deprecated a bunch of methods that where already deprecated at an earlier point. We are still building out our web support and do not want to rely upon already deprecated methods from the beginning.
We are also waiting for the upcoming http 2.0 release (it will make a lot of work easier for us) and as mentioned above it already requires web 0.5. We'd like to already have the way paved for when the release comes.

[vbuberen]

Could you please explain me how this is going to be breaking?

I wouldn't like to move the min required Flutter and Dart that fast and lose compatibility with lots of projects that still didn't update. I know that bumping versions like that will just not resolve the dependency for such projects, but still, as I said I am against increasing min versions for no reason.

Have a look at the http package from the dart team that did a similar change with a patch version bump

I have already seen it and it doesn't mean anything as Plug Plugins aren't plugins of Google or Dart teams, so their decisions like that are not something that should be followed by everyone without questions.

There are multiple reasons as to why we want to move to move to web 0.5.
One is not wanting to fall behind on a package that evolves quite fast.
Another is that web 0.5 re deprecated a bunch of methods that where already deprecated at an earlier point. We are still building out our web support and do not want to rely upon already deprecated methods from the beginning.
We are also waiting for the upcoming http 2.0 release (it will make a lot of work easier for us) and as mentioned above it already requires web 0.5. We'd like to already have the way paved for when the release comes.

It all seems clear and logical, but I don't see an answer to my question why extending the range in package_info_plus to include 0.5 as well (say to 0.6) won't satisfy your needs? At the moment package_info_plus doesn't need to drop older web versions as far as I understand, so I would instead suggest to return version range, but change it to web: '>=0.3.0 <0.6.0' and call it a day.
It would be much better and something that I would support to let projects like the one you are working on to go with the latest and greatest while still allow older ones to get fixes/changes that we might introduce in nearest time.

[Leptopoda]

Ok I just checked again and it looks like the flutter bump wouldn't even be needed (no Idea what lead to me beveling this initially).
I myself have nothing against widening the version range. I initially thought that this might lead to issues with the new deprecations and renames but as package_info_plus does not use any there shouldn't be any issues.

Sorry for the noise :)

[Leptopoda]

Just out of personal interest. I don't feel like you have mentioned why the you (the plus plugin maintainers) consider a major version bump of dependencies to be breaking.
I understand that you don't have to follow the dart team and that you try to support a wide range of users.
But how would a flutter version bump be breaking in the means of semantic versioning.

[vbuberen]

I don't feel like you have mentioned why the you (the plus plugin maintainers) consider a major version bump of dependencies to be breaking.

I have already explained to you that the question is in compatibility, not in breaking functionality or semantic versioning. I am not a fan of this let's bump min version of Dart/Flutter without doing a version bump and it will just not suggest to users with other dependencies.

[vbuberen]

This change is much better. Thanks for updating your PR.

[Leptopoda]

@vbuberen can you provide a rough estimate on when you plan to do the next release?

[vbuberen]

Somewhere in March

[xvrh]

@vbuberen can we please 🙏 release this change? It just widen the constraints and would allow to upgrade other packages that requires web 0.5.0. Thanks.

[Leptopoda]

As seen above we are going with a dependency override for now. So definitely also +1 from us.

[vbuberen]

can we please 🙏 release this change? It just widen the constraints and would allow to upgrade other packages that requires web 0.5.0. Thanks.

No, unfortunately can't this time. We have a set of other changes that we want to have in the next release as next release is planned to be a breaking change for all plugins anyway. Currently we already have some other PRs merged already like bump min macOS version which we consider as breaking. And there are no plans to do a cherrypick for this single change to do a release for now.
With that being said I would advice to specify a ref to a commit in main instead of pub version for now and change it back when the plugin update is released.

Locking this conversation as I have already replied about the timeline.