[http] Migrate to the latest pkg:web, require Dart 3.3

[kevmoo]

No description provided.

[vanlooverenkoen]

@kevmoo is it normal that this is a minor version bump?

[kevmoo]

@vanlooverenkoen "normal"? I think so.

[vanlooverenkoen]

@kevmoo I would think that if we require something it would result in a breaking change.

MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backward compatible manner
PATCH version when you make backward compatible bug fixes

1.2.1 is not backwards compatible with 1.2.0 so feel like this is not "normal" when following semantic versioning.

What if for example 1.2.0 has a major security issue? We can not create a patch for 1.2.0 on 1.2.1? because it already exist. And we also can not use 1.2.2 because 1.2.1 already requires a higher dart sdk?

Or am I missing something.

[kevmoo]

What is not backward compatible in 1.2.1 compared to 1.2.0?

[vanlooverenkoen]

This is my project:

I am currently on Flutter 3.16.9 & dart 3.2.6

This works fine:

environment:
  sdk: ">=2.18.4 <3.0.0"
  flutter: ^3.7.0

dependencies:
  flutter:
    sdk: flutter
  http: ^1.2.0
  intl: ^0.18.1

dev_dependencies:
  flutter_test:
    sdk: flutter
  flutter_lints: ^2.0.0

This fails:

environment:
  sdk: ">=2.18.4 <3.0.0"
  flutter: ^3.7.0

dependencies:
  flutter:
    sdk: flutter
  http: ^1.2.1 # updated to 1.2.1 from 1.2.0
  intl: ^0.18.1

dev_dependencies:
  flutter_test:
    sdk: flutter
  flutter_lints: ^2.0.0

with this error:

Resolving dependencies...
The current Dart SDK version is 3.2.6.

Because my_app depends on http >=1.2.1 which requires SDK version ^3.3.0, version solving failed.


You can try the following suggestion to make the pubspec resolve:
* Consider downgrading your constraint on http: flutter pub add http:^1.2.0

So 1.2.1 is not compatible with 1.2.0 which should be based on semantic versioning.

[kevmoo]

Being unable to get the latest version does not mean it's incompatible. Everything works fine if you just get 1.2.0.

[vanlooverenkoen]

Yes I know that 1.2.0 works, but that is not my point. What happens if http 1.2.0 has a major security issue? It is not possible to patch 1.2.0 because 1.2.1 is already created and requires a newer dart version. Which is incompatible with dart 3.2.x.

[kevmoo]

@vanlooverenkoen – we will publish 1.2.0+1 🤷

[vanlooverenkoen]

Is that the semantic versioning standard? I would think that bugs on 1.2.0 should be fixed in 1.2.1?

[kevmoo]

@vanlooverenkoen functionally I don't know if it'd affect folks.

[vanlooverenkoen]

We have had countless issues with maintainers updating a breaking change in a minor version. Or requiring a breaking change dependency in a package we were using. Resulting in bug or our project not being able to compile. It would be nice if we could have a community standard on which we can rely for versioning.

I feel like we (as a community) are using semantic versioning as we please and not following the actual standard.

[natebosch]

We have had countless issues with maintainers updating a breaking change in a minor version.
...
Resulting in bug or our project not being able to compile.

A breaking change in a minor version describes a situation where you make no change to pubspec.yaml but a dart pub upgrade makes an app fail to compile. That is not the situation described above. An inability to pub solve to a new package patch version is not a breaking change.

Or requiring a breaking change dependency in a package we were using.

A change to dependency compatibilities is not a breaking change. Being unable to pub solve to new package versions which depend on an SDK you don't have is working as intended. I have not read a spec for semantic versioning which requires major version changes for any incompatible dependency change.

I don't think the flutter SDK pins package:http, so I don't think any flutter SDK update should break working compiles or pub solves as it relates to this package.

Manually updating a dependency to the latest published patch version and expecting it to continue to pub solve correctly is not a supported workflow.

I feel like we (as a community) are using semantic versioning as we please and not following the actual standard.

I can't speak for the entire community, but in my opinion the Dart team owned packages and the Dart SDK have mostly followed semver principles and the deviations we've had have been pragmatic and low impact.

Flutter SDK doesn't use semantic versioning, but I think most flutter plugins published to pub strive to.