pub_semver 1.4.1

  • Installing
  • Versions
  • 98

Handles version numbers and version constraints in the same way that pub does. The semantics here very closely follow the Semantic Versioning spec. It differs from semver in a few corner cases:

  • Version ordering does take build suffixes into account. This is unlike semver 2.0.0 but like earlier versions of semver. Version 1.2.3+1 is considered a lower number than 1.2.3+2.

    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:

    • 1.0.0
    • 1.1.0
    • 1.2.0
    • 2.0.0-alpha
    • 2.0.0-beta
    • 2.0.0
    • 2.1.0

    Versions 2.0.0 and 2.1.0 are excluded by the constraint since neither matches <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 the <2.0.0 constraint does technically allow those.

    But that's almost never what the user wants. If their package doesn't work with foo 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 represent.

    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 just 2.0.0 but any pre-release of 2.0.0. However, <2.0.0-beta will exclude 2.0.0-beta but allow 2.0.0-alpha. Likewise, >2.0.0-alpha <2.0.0 will exclude 2.0.0-alpha but allow 2.0.0-beta.

  • 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:

    • 1.0.0
    • 1.2.0-alpha
    • 1.2.0
    • 1.3.0-experimental

    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 mean 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:

    • 1.2.0-alpha
    • 1.3.0-experimental
    • 1.0.0
    • 1.2.0

    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:

    0.0.3 -> 0.1.0 0.7.2-alpha -> 0.8.0 1.2.3 -> 2.0.0

    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.


  • Fix a bug where there upper bound of a version range with a build identifier could accidentally be rewritten.


  • Add a Version.firstPreRelease getter that returns the first possible pre-release of a version.

  • Add a Version.isFirstPreRelease getter that returns whether a version is the first possible pre-release.

  • new VersionRange() with an exclusive maximum now replaces the maximum with its first pre-release version. This matches the existing semantics, where an exclusive maximum would exclude pre-release versions of that maximum.

    Explicitly representing this by changing the maximum version ensures that all operations behave correctly with respect to the special pre-release semantics. In particular, it fixes bugs where, for example, (>=1.0.0 <2.0.0-dev).union(>=2.0.0-dev <2.0.0) and (>=1.0.0 <3.0.0).difference(^1.0.0) wouldn't include 2.0.0-dev.

  • Add an alwaysIncludeMaxPreRelease parameter to new VersionRange(), which disables the replacement described above and allows users to create ranges that do include the pre-release versions of an exclusive max version.


  • Fix more bugs with VersionRange.intersect(), VersionRange.difference(), and VersionRange.union() involving version ranges with pre-release maximums.


  • Fix a bug where constraints that only allowed pre-release versions would be parsed as empty constraints.


  • Fix a bug where VersionRange.intersect() would return incorrect results for pre-release versions with the same base version number as release versions.


  • Fix a bug where VersionRange.allowsAll(), VersionRange.allowsAny(), and VersionRange.difference() would return incorrect results for pre-release versions with the same base version number as release versions.


  • Fix a bug where VersionRange.difference() with a union constraint that covered the entire range would crash.


  • Fix a checked-mode error in VersionRange.difference().


  • Fix a new strong mode error.


  • Make the VersionUnion class public. This was previously used internally to implement new VersionConstraint.unionOf() and VersionConstraint.union(). Now it's public so you can use it too.

  • Added VersionConstraint.difference(). This returns a constraint matching all versions matched by one constraint but not another.

  • Make VersionRange implement Comparable<VersionRange>. Ranges are ordered first by lower bound, then by upper bound.


  • Fix all remaining strong mode warnings.


  • Addressed three strong mode warnings.


  • Make the package analyze under strong mode and compile with the DDC (Dart Dev Compiler). Fix two issues with a private subclass of VersionConstraint having different types for overridden methods.


  • Allow version ranges like >=1.2.3-dev.1 <1.2.3 to 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.


  • Add a VersionConstraint.union() method and a new VersionConstraint.unionOf() constructor. These each return a constraint that matches multiple existing constraints.

  • Add a VersionConstraint.allowsAll() method, which returns whether one constraint is a superset of another.

  • Add a VersionConstraint.allowsAny() method, which returns whether one constraint overlaps another.

  • Version now implements VersionRange.


  • Add support for the ^ operator for compatible versions according to pub's notion of compatibility. ^1.2.3 is equivalent to >=1.2.3 <2.0.0; ^0.1.2 is equivalent to >=0.1.2 <0.2.0.

  • Add Version.nextBreaking, which returns the next version that introduces breaking changes after a given version.

  • Add 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.


  • Initial release.

Use this package as a library

1. Depend on it

Add this to your package's pubspec.yaml file:

  pub_semver: "^1.4.1"

2. Install it

You can install packages from the command line:

with pub:

$ pub get

with Flutter:

$ flutter packages get

Alternatively, your editor might support pub get or flutter packages get. Check the docs for your editor to learn more.

3. Import it

Now in your Dart code, you can use:

      import 'package:pub_semver/pub_semver.dart';
Version Uploaded Documentation Archive
1.4.1 May 2, 2018 Go to the documentation of pub_semver 1.4.1 Download pub_semver 1.4.1 archive
1.4.0 May 2, 2018 Go to the documentation of pub_semver 1.4.0 Download pub_semver 1.4.0 archive
1.3.7 Apr 13, 2018 Go to the documentation of pub_semver 1.3.7 Download pub_semver 1.3.7 archive
1.3.6 Apr 10, 2018 Go to the documentation of pub_semver 1.3.6 Download pub_semver 1.3.6 archive
1.3.5 Apr 5, 2018 Go to the documentation of pub_semver 1.3.5 Download pub_semver 1.3.5 archive
1.3.4 Apr 3, 2018 Go to the documentation of pub_semver 1.3.4 Download pub_semver 1.3.4 archive
1.3.3 Mar 30, 2018 Go to the documentation of pub_semver 1.3.3 Download pub_semver 1.3.3 archive
1.3.2 Nov 21, 2016 Go to the documentation of pub_semver 1.3.2 Download pub_semver 1.3.2 archive
1.3.1 Nov 16, 2016 Go to the documentation of pub_semver 1.3.1 Download pub_semver 1.3.1 archive
1.3.0 Jun 8, 2016 Go to the documentation of pub_semver 1.3.0 Download pub_semver 1.3.0 archive

All 17 versions...


We analyzed this package on Jun 12, 2018, and provided a score, details, and suggestions below. Analysis was completed with status completed using:

  • Dart: 2.0.0-dev.60.0
  • pana: 0.11.3


Describes how popular the package is relative to other packages. [more]
95 / 100
Code health derived from static analysis. [more]
100 / 100
Reflects how tidy and up-to-date the package is. [more]
100 / 100
Overall score:
Weighted score of the above. [more]
Learn more about scoring.


Detected platforms: Flutter, web, other

No platform restriction found in primary library package:pub_semver/pub_semver.dart.


  • Maintain an example.

    Create a short demo in the example/ directory to show how to use this package. Common file name patterns include: main.dart, example.dart or you could also use pub_semver.dart.


Package Constraint Resolved Available
Direct dependencies
Dart SDK >=1.0.0 <2.0.0
collection >=0.9.0 <2.0.0 1.14.10
Dev dependencies
test >=0.12.0 <0.13.0