The Problem

It is common practice to use these signs when managing the dependencies. It is even recommended as a best practice. Today, I will declare an anomalous idea.

When you use +, ^, or … signs for the versions of dependencies, Flutter Package Manager finds the correct version for you. During the active development that is useful. And using the latest versions is a good thing, right?

Well, most of the time. If the project is a long-term and multi-developer project, things become to change.

The problem appears in three main cases:

1. When updating the packages to unwanted versions.

2. When you open your project months or years later

3. When someone else opens your project.

Updating The Packages To Unwanted Version

Some of the Flutter packages need native plugins and maintaining native plugins is kinda hard. There are two platforms to manage, every platform divides into versions, and every version can behave differently. Even the same versions of Android can behave differently according to the manufacturer. The developer of the package should test all of these combinations, and as you can see, that requires some time.

Even if the package compiles and runs without any error, the behavior of the package may be changed in the next build. That happens even for the Flutter itself.
That situation usually happens the night before the deadline.

When you open your project months or years later

That means the development machine may contain different versions of the packages and even a different version of Flutter. That may break the build or change the behavior of the app.

When someone else opens your project

If the project you working on is a long-term project, probably you or one of your colleagues will open the projects months later. That means whole different development environments and versions. She/he needs to make a quick fix, or add functionality and send an update. That process carries risks I mentioned before and creates really high pressure on the developer. The camera button started crashing the app and you changed only a typo? That may the reason.

As you can see, all these ranged versions are like mud under a building. Building is fine, but it may take serious damage at the very first action.

The Solution

To prevent yourself and other developers from these problems and make the project more maintainable, follow a simple rule:

determine all versions. including the Dart SDK, Flutter and dependencies.

To do that, follow two simple steps:

1. Determine the Dart SDK version

In pubspec.yaml file find the SDK version:

As you see, it is a range. We are gonna change that.

In the terminal, write flutter –version to the terminal. That command will give the version you use on your machine.
flutter –version

The important line is Tools Dart 2.13.0, which is the version I use. Pick your version here and write to pubspec file.

Bonus: You can paste the versions to the pubspec file just to write down a note to the future developer.

2. Determine Packages Versions

You can find all versions of your packages in packages.lock file. Just copy the current version here and paste it into pubspec.yaml file.

As you see, there are two packages here. Get package does not has a version so it will keep being updated. get_storage package has a ^ sign and probably it will also be updated. Versions of both packages are saved under pubspec.lock file.

Open pubspec.lock and find the packages here. Get package first:

We can see the version here, it is “4.1.4”. I will copy that version and paste it to pubspec.yaml. Here is the result:

Just to be sure everything is fine, install all packages again, stop the running and rebuild the project.

And same for the get_storage dependency: open the pubspec.lock file and copy the version here.
Note: Even get_storage has a version, because of the ^ and + signs it can be a different version in pubspec.lock file. The installed version is in pubspec.lock file.

Here it is:

And I determined the version of the get_storage package.

The project is safe now. You can be sure it will be compiled in the future. Even if the future developer does not have the versions, they can install the correct versions.

Here is the final result:

That’s all.
Thanks.