anchor.diff:  ==>[value:santa fe,startTime:2005]
   ```
   
  -As shown above, the support of the `with()` modulator for `valueMap()` makes the `valueMap(boolean)` overload superfluous, hence this overload is now deprecated. This is a breaking API change, since
  -`valueMap()` will now always yield instances of type `Map<Object, Object>`. Prior this change only the `valueMap(boolean)` overload yielded `Map<Object, Object>` objects, `valueMap()` without the
  -boolean parameter used to yield instances of type `Map<String, Object>`.
  +As shown above, the support of the `with()` modulator for `valueMap()` makes the `valueMap(boolean)` overload
  +superfluous, hence this overload is now deprecated. This is a breaking API change, since `valueMap()` will now always
  +yield instances of type `Map<Object, Object>`. Prior this change only the `valueMap(boolean)` overload yielded
  +`Map<Object, Object>` objects, `valueMap()` without the boolean parameter used to yield instances of type
  +`Map<String, Object>`.
   
   See: link:https://issues.apache.org/jira/browse/TINKERPOP-2059[TINKERPOP-2059]
   
   ==== Number Comparison of Predicates
   
  -In previous versions `within()` and `without()` performed strict number comparisons; that means these predicates did not only compare number values, but also the time. This was inconsistent with
  -how other predicates (like `eq, `gt`, etc.) work. All predicates will now ignore the number type and instead compare numbers only based on their value.
  +In previous versions `within()` and `without()` performed strict number comparisons; that means these predicates did
  +not only compare number values, but also the type. This was inconsistent with how other predicates (like `eq, `gt`,
  +etc.) work. All predicates will now ignore the number type and instead compare numbers only based on their value.
   
   Old behavior:
   
  
positive.code: ==>[a:marko]
  ----
  
  Above is the old behavior; the second `select("a")` has no effect, it selects the side-effect `a` again, although one would expect to get the map entry `a`. What follows is the new behavior:
  
  [source,groovy]
  ----
  
negative.code: ==>[software:0,person:3.5]
  ----
  
  Since software vertices have no outgoing edges and thus no weight values to sum, `software` will no longer show up in
  the result. In order to get the same result as before, one would have to add a `coalesce()`-step:
  
  [source,groovy]
  ----
  