Dart: What is the difference between the "Upgradable" and "Resolvable" columns in the output of "dart pub outdated"? - flutter

What is the difference between the "Upgradable" and "Resolvable" columns in the output of "dart pub outdated"?
Here is an example of a package that can be upgraded to the latest. The Upgradable, Resolvable, and Latest all match:
url_launcher *6.0.11 6.0.12 6.0.12 6.0.12
Here is an example of a package that is already at the highest resolvable version, but can't be upgraded to the absolute latest version. Presumably another dependency is restricting the resolvability to the latest.
rxdart *0.26.0 *0.26.0 *0.26.0 0.27.2
Here is an example of a package that can't be upgraded any higher but has a Resolvable version that is higher. What does this mean? How is this different from the middle case above?
provider *5.0.0 *5.0.0 6.0.1 6.0.1

In addition to the other very useful posted thoughts, I have learned the following helpful details:
Upgradable refers to the highest version that your direct pubspec will permit, which considers the sdk version and the individual package version (whether to upgrade to just minor or also major). When Upgradable is limited, it can likely be your sdk version holding things back. In my case I was using sdk 2.12, but some packages require 2.14 now (Sep 2021).
From the docs:
The latest version allowed by your pubspec.yaml file. This is the version that dart pub upgrade resolves to. The value is - if the value in the Current column is -.
Resolvable refers to the highest version that all of the other packages' dependencies will allow, in addition to your direct pubspec constraints. When the Resolvable is limited, there is usually one package holding everything back, or a major version holding everything back.
From the docs:
The latest version that can be resolved, when combined with all other dependencies. This version corresponds to what dart pub upgrade gives you if all version constraints in pubspec.yaml are unbounded. A value of - means that the package won’t be needed.

Upgradable means an upgradeable version. Generally, minor version updates can be upgraded directly without modification.
Resolvable can use the version, generally a major version update (the 0.x version may have destructive changes, same as major version), may have incompatible interfaces to the previous version, if you update this version, you may need to change some code
Latest The latest version. If it is inconsistent with the Resolvable version, means the SDK version required by the latest version is inconsistent with the current project

The main difference is that Resolvable mains the version you need to reach to resolve outdated issues in your project and Upgradable mains the version you can update of that package.
To resolve it you must find packages you can update and continue updating until you can update the main package.
You can see it in this link about those concepts: Dart pub outdated

Related

Upgrading projects Flutter SDK, migration to null-safety - compile time errors in packages

We have decided to upgrade the Flutter version from 1.22 to 2.0 (migrating to null-safety) in an existing project.
We checkout Flutter v2.0.0 and then run the following command:
dart pub upgrade --null-safety
Flutter nicely resolves all dependency conflicts and sets new versions for packages.
Without changing min environment SDK in pubspec.yaml (staying at ">2.10.0 <3.0.0") we fix all breaking changes in the code.
All errors in vs code disappear so we can compile the code. But, when we do compile we get errors from packages e.g. reorderables, fl_chart, flutter_svg etc. stating some classes are undefined. It seems like packages were compiled with a higher SDK version and they weren't set min SDK version to match the one that they were compiled with.
So the package states it can be compiled with Flutter 2.10.0 but in reality, it fails to compile because in this version of Flutter it is missing some necessary imports.
My question is, is this a problem of packages or a problem in my way of processing with migration?
Is it that packages are lacking properly set min SDK?
My conclusion is that most packages are lacking correctly set SDK version constraints. It seems authors usually compile packages for a certain version and do not check min SDK version required. When running dependency resolver it seems to solve dependencies but in compile time it fails.

Version solving for certain package versions failed in flutter

I have received this kind error a couple of time before with different packages, usually i just try a combination of different versions till i finally get a match that works. Is there a way to know what package versions are compatible instead of using the trial error approach which is outright time consuming and exhausting.
Initially i though it could be that one of the packages depends on the other, like in this case maybe flutter_svg depends on a different version of flutter_luban so the version in my pubspec clashes with it, but none of these packages depend on one another after viewing the respective package dependencies.
pub get failed (1; So, because sakaHapa depends on both
flutter_svg ^0.17.4 and flutter_luban ^0.1.13, version solving
failed.)
You can use 'pub outdated' command like below.
https://dart.dev/tools/pub/cmd/pub-outdated
Here is column what means.
Current
The version used in your package, as recorded in pubspec.lock. If the package isn’t in pubspec.lock, the value is -.
Upgradable
The latest version allowed by your pubspec.yaml file. This is the version that dart pub upgrade resolves to. The value is - if the value in the Current column is -.
Resolvable
The latest version that can be resolved, when combined with all other dependencies. This version corresponds to what dart pub upgrade gives you if all version constraints in pubspec.yaml are unbounded. A value of - means that the package won’t be needed.
Latest
The latest version of the package available, excluding prereleases unless you use the option --prereleases.
flutter pub outdated

Revising a previously published Dart package version

I have published many versions of a Dart package, but I want to go back an update a previous version. Let's say I have published these versions:
1.0.0 - first version
1.1.0 - minor update
2.0.0 - major update with breaking changes
I would like to go back and publish version 1.2.0 with a small change to 1.1.0 code, but not use the 2.0.0 code. If I use pub publish with version 1.2.0, will it add it to the versioning list correctly, or will it use publish date order instead?
I believe that it should work correctly, and if it doesn't, it would be a bug that should be reported.
As an example, the versions of the path_provider package show that version 1.6.28 was uploaded after 2.0.0 and 2.0.1, but 2.0.1 (as of writing) is advertised as the latest stable version.

Visual Studio 2019 Nuget cannot find a package

My packages.config has this entry:
<package id="xxxxxx" version="3.0.0" allowedVersions="[3.0,3.3)" targetFramework="net452">
Now there is no package xxxxxxx at version 3.0.0 (there might have been, once upon a time), but I am allowing anything between 3.0 and 3.3. I do have a package at 3.1.0, and I expected that nuget would find that one and pick it up, but I get the error
Unable to find version '3.0.0' of package xxxxxxxx
Questions:
Why does nuget not say, "oh I can't find 3.0.0 but I'm allowed to use anything from 3.0 to 3.3 and I have 3.1.0. I'll use that!"
What is the correct config to use to make it pick up the highest available version in the allowed range?
In packages.config, every dependency is listed with an exact
version attribute that's used when restoring packages. The
allowedVersions attribute is used only during update operations to
constrain the versions to which the package might be updated.
Source: https://learn.microsoft.com/en-us/nuget/concepts/package-versioning#references-in-project-files-packagereference
If you want to use ranges in your project, you will have to switch to References in project files (PackageReference), but keep in mind:
NuGet 2.8.x and earlier chooses the latest available package version
when resolving a dependency, whereas NuGet 3.x and later chooses the
lowest package version.
Option to always resolve to highest version was proposed and rejected: https://github.com/NuGet/Home/issues/1192

What is the caret sign (^) before the dependency version number in Flutter's pubspec.yaml?

In the pubspec.yaml file of my Flutter project there is a caret (^) before the version number of some of the dependencies.
dependencies:
flutter:
sdk: flutter
cupertino_icons: ^0.1.2
english_words: ^3.1.5
What is its purpose? What does it mean?
Notes
I looked in the yaml documentation but I didn't see anything that made sense.
Related: what does Caret sign do in Dart (but it isn't an XOR operator here)
Related: In Flutter, Dependencies must specify version number? (an answer pointed me in the right direction but the question is asking something different)
The caret sign (^) is used for pub dependencies in Dart to indicate a range of version numbers are allowed. Specifically, any version from the specified version up to (but not including) the next non-breaking version is ok.
So ^3.1.5 is the same as '>=3.1.5 <4.0.0'
And ^1.2.3 would be the same as '>=1.2.3 <2.0.0'
It's shorthand for the longer form.
The ^ is saying, I want to automatically use the most up-to-date package from Pub as long as that update won't break anything in my app.
Notes
The concept of Semantic Versioning is important here. Read the article at the link if you are not familiar with it.
Version constraints documentation
Caret syntax documentation
Clarification for versions less than 1.0.0
Originally I had thought that
^0.1.2 is the same as '>=0.1.2 <1.0.0' (wrong!)
However, that is an incorrect understanding of Semantic Versioning. When the major version number is 0 (as in the 0 of 0.1.2), the meaning is that the API is unstable and even minor version number changes (as in the 1 of 0.1.2) can indicate a breaking change.
The Semantic Versioning article states:
Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
and also
How should I deal with revisions in the 0.y.z initial development
phase?
The simplest thing to do is start your initial development release at
0.1.0 and then increment the minor version for each subsequent release.
Thus, the following is the corrected form:
^0.1.2 is the same as '>=0.1.2 <0.2.0'
Thank you to Günter Zöchbauer for pointing out my error.
See also
How do Dart Package Versions work & how should I version my Flutter Plugins?
The caret sign ^ means the specified version and all newer versions that don't introduce breaking changes relative to the specified version.
Dart follows Semantic Versioning and suggests that to be used for package maintainers as well.
Semantic Versioning defines that
For versions >= 1.0.0, the major version needs to be incremented for breaking changes.
For versions < 1.0.0, the minor version needs to be incremented for breaking changes.
Example:
^2.4.3 means >= 2.4.3 < 3.0.0
^0.17.19 means >= 0.17.19 <0.18.0
It means that any new versions of a dependency that does not contain breaking changes will be accepted.
Dart language follows semantic versioning and uses it for package maintainers.
In layman's terms ^1.8.1 means >= 1.8.1 < 2.0.0