Version ordering does take build suffixes into account. This is unlike
semver 2.0.0 but like earlier versions of semver. Version
considered a lower number than
Since a package may have published multiple versions that differ only by build suffix, pub still has to pick one of them somehow. Semver leaves that issue unresolved, so we just say that build numbers are sorted like pre-release suffixes.
Pre-release versions are excluded from most max ranges. Let's say a
user is depending on "foo" with constraint
>=1.0.0 <2.0.0 and that "foo"
has published these versions:
2.1.0 are excluded by the constraint since neither
<2.0.0. However, since semver specifies that pre-release versions
are lower than the non-prerelease version (i.e.
2.0.0-beta < 2.0.0, then
<2.0.0 constraint does technically allow those.
But that's almost never what the user wants. If their package doesn't work
2.0.0, it's certainly not likely to work with experimental,
unstable versions of
2.0.0's API, which is what pre-release versions
To handle that,
< version ranges don't allow pre-release versions of the
maximum unless the max is itself a pre-release, or the min is a pre-release
of the same version. In other words, a
<2.0.0 constraint will prohibit not
2.0.0 but any pre-release of
2.0.0-beta but allow
<2.0.0 will exclude
2.0.0-alpha but allow
Pre-release versions are avoided when possible. The above case handles pre-release versions at the top of the range, but what about in the middle? What if "foo" has these versions:
When a number of versions are valid, pub chooses the best one where "best"
usually means "highest numbered". That follows the user's intuition that,
all else being equal, they want the latest and greatest. Here, that would
1.3.0-experimental. However, most users don't want to use unstable
versions of their dependencies.
We want pre-releases to be explicitly opt-in so that package consumers don't get unpleasant surprises and so that package maintainers are free to put out pre-releases and get feedback without dragging all of their users onto the bleeding edge.
To accommodate that, when pub is choosing a version, it uses priority order which is different from strict comparison ordering. Any stable version is considered higher priority than any unstable version. The above versions, in priority order, are:
This ensures that users only end up with an unstable version when there are no alternatives. Usually this means they've picked a constraint that specifically selects that unstable version -- they've deliberately opted into it.
There is a notion of compatibility between pre-1.0.0 versions. Semver deems all pre-1.0.0 versions to be incompatible. This means that the only way to ensure compatibility when depending on a pre-1.0.0 package is to pin the dependency to an exact version. Pinned version constraints prevent automatic patch and pre-release updates. To avoid this situation, pub defines the "next breaking" version as the version which increments the major version if it's greater than zero, and the minor version otherwise, resets subsequent digits to zero, and strips any pre-release or build suffix. For example, here are some versions along with their next breaking ones:
To make use of this, pub defines a "^" operator which yields a version constraint greater than or equal to a given version, but less than its next breaking one.
VersionUnion class public. This was previously used internally to
new VersionConstraint.unionOf() and
Now it's public so you can use it too.
VersionConstraint.difference(). This returns a constraint matching all
versions matched by one constraint but not another.
Comparable<VersionRange>. Ranges are ordered
first by lower bound, then by upper bound.
VersionConstrainthaving different types for overridden methods.
>=1.2.3-dev.1 <1.2.3to match pre-release versions of
1.2.3. Previously, these didn't match, since the pre-release versions had the same major, minor, and patch numbers as the max; now an exception has been added if they also have the same major, minor, and patch numbers as the min and the min is also a pre-release version.
VersionConstraint.union() method and a
VersionConstraint.unionOf() constructor. These each return a constraint that
matches multiple existing constraints.
VersionConstraint.allowsAll() method, which returns whether one
constraint is a superset of another.
VersionConstraint.allowsAny() method, which returns whether one
constraint overlaps another.
Version now implements
Add support for the
^ operator for compatible versions according to pub's
notion of compatibility.
^1.2.3 is equivalent to
is equivalent to
Version.nextBreaking, which returns the next version that introduces
breaking changes after a given version.
new VersionConstraint.compatibleWith(), which returns a range covering
all versions compatible with a given version.
Add a custom
VersionRange.hashCode to make it properly hashable.
Add this to your package's pubspec.yaml file:
dependencies: pub_semver: "^1.3.2"
You can install packages from the command line:
$ pub get
$ flutter packages get
Alternatively, your editor might support
pub get or
Check the docs for your editor to learn more.
Now in your Dart code, you can use:
|1.3.2||Nov 21, 2016|
|1.3.1||Nov 16, 2016|
|1.3.0||Jun 8, 2016|
|1.2.4||Apr 1, 2016|
|1.2.3||Nov 2, 2015|
|1.2.2||Sep 21, 2015|
|1.2.1||May 21, 2015|
|1.2.0||May 6, 2015|
|1.1.0||Oct 29, 2014|
|1.0.0||Sep 26, 2014|
We analyzed this package, and provided a score, details, and suggestions below.
Describes how popular the package is relative to other packages. [more]
Code health derived from static analysis. [more]
Reflects how tidy and up-to-date the package is. [more]
Weighted score of the above. [more]
Detected platforms: Flutter, web, other
No platform restriction found in primary library
Maintain an example.
Create a short demo in the
example/directory to show how to use this package. Common file name patterns include:
example.dartor you could also use