# pub_semver 1.2.2

Versions and version constraints implementing pub's versioning policy. This is very similar to vanilla semver, with a few corner cases.





## Installing
```
export PUB_HOSTED_URL=https://pub.mirror.p-hatan.ir
flutter pub add 'pub_semver:1.2.2'
```
Published: 2015-09-21T20:09:17.380Z
Expected archive SHA-256: dbcd22a9870b03baff520763941f566c2c05b319ce64ee4fe2d1c32d8d89a4d0

Available in cache; verification: upstream_checksum
## Direct dependencies
- collection: >=0.9.0 <2.0.0

## Package README (untrusted upstream documentation)
Handles version numbers and version constraints in the same way that [pub][]
does. The semantics here very closely follow the [Semantic Versioning][semver]
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.

[pub]: http://pub.dartlang.org/
[semver]: http://semver.org/

## Changelog
# 1.2.2

* 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.

# 1.2.1

* 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.

# 1.2.0

* 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`.

# 1.1.0

* 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.

# 1.0.0

* Initial release.