Change the pre-release range semantics.

README.md

 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
@@ skipping 15 matching lines @@
     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 to not allow pre-release versions of the
-    maximum unless the max is itself a pre-release. 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`.
+    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`
 
@@ skipping 37 matching lines @@
     `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/