anchor.diff:  |===
   | Which version(s) of this dependency are acceptable? | `strictly` | `require` | `prefer` | `rejects` | Selection result
   
  -| Tested with version `1.5`, believe all future versions should work
  +| Tested with version `1.5`, believe all future versions should work.
   |
   | 1.5
   |
   |
   | Any version starting from `1.5`, equivalent of `org:foo:1.5`. An upgrade to `2.4` is accepted.
   
  -| Tested with `1.5`, soft constraint upgrades according to semantic versioning
  +| Tested with `1.5`, soft constraint upgrades according to semantic versioning.
   |
   | [1.0, 2.0[
   | 1.5
  
positive.code: Another concept that relates with rich version declaration is the ability to publish <<publishing_maven.adoc#publishing_maven:resolved_dependencies,resolved versions>> instead of declared ones.
  
  
  Using `strictly`, especially for a library, must be a well thought process as it can have a serious impact on downstream consumers.
  At the same time, used correctly, it will help consumers understand what combination of libraries do not work together in their context.
  
  
  [NOTE]
  
negative.code: `strictly`::
  Any version not matched by this version notation will be excluded.
  This is the strongest version declaration.
  On a declared dependency, a `strictly` can downgrade a version.
  When on a transitive dependency, it will cause dependency resolution to fail if no version acceptable by this clause can be selected.
  See <<controlling_transitive_dependencies.adoc#sec:enforcing_dependency_version,overriding dependency version>> for details.
  This term supports dynamic versions.
  +
  When defined, overrides previous `require` declaration and clears previous `reject`.
  