"pub downgrade" may resolve with package versions incompatible with Dart 3

[rrousselGit]

Hello!

There appears to be an unfortunate side-effect to treating constraints such as sdk: >=2.x.z <3.0.0 as sdk: >=2.x.z <4.0.0.
This effectively marks versions non-compatible with the breaking changes in Dart 3.0 to be compatible with it anyway.

As an example, consider a package A that:

• in version 1.0.0 is using NullThrownError, which was removed in Dart 3
• has for SDK constraint sdk: >=2.x.z <3.0.0, which matches with what the package supports
• has a more recent version 1.1.0 available that is Dart 3 compatible (as in, its sdk constraint explicitly allows Dart 3)

Then, a second package B depends on package A, but with looser version constraints.

• package B is compatible with both Dart 2 and Dart 3
• package B is also compatible with all versions of package A

In that situation, B has effectively for pubspec:

name: b
environment:
  sdk: ">=2.12.0 <4.0.0"
dependencies:
  a: ^1.0.0

With those constraints, there is now an issue when running pub downgrade on an app depending on B when using Dart 3.

Instead of resolving the version of A with v1.1.0 which is Dart 3 compatible, the command will resolve with v1.0.0 which is not Dart 3 compatible.
As such, the application will fail to start.

This is confusing because, at all points, the package authors and application authors used the correct version constraints.

• The author of A correctly said Dart 3 wasn't supported in their version 1.0.0 and correctly published a newer Dart 3 compatible version
• The author of B correctly supports Dart 2 and 3 at the same time
• The app author which depends on B doesn't use A, so they shouldn't have to care about the minimum A version

[rrousselGit]

One possible solution could be to treat <3.0.0 as <4.0.0 only if a package doesn't include a published non-dev version compatible with Dart 3.

[mit-mit]

cc @sigurdm @jonasfj

[sigurdm]

This is not really about downgrades or about the special treatment of the constraints, but a general fact of the way we introduce breaking changes without bumping the version number. (https://github.com/dart-lang/sdk/blob/main/docs/process/breaking-changes.md#dart-compatibility-and-philosophy see the point about "evolution").

Here the situation looks special because we did have a bump of the major version number, and we did indeed make more breaking changes than usual.

Dart 3.0 claims to be backwards compatible back to 2.12 (in terms of the special treatment of sdk constraints), that is just not true - there are breaking changes, that are not modelled in semver.
Also 2.19 had breaking changes: https://github.com/dart-lang/sdk/blob/main/CHANGELOG.md#2190---2023-01-24 .

[sigurdm]

It is possible to write an sdk constraint such that it doesn't get rewritten (>=2.12.0 <2.99.0) but there is no way to update already published packages.