Docs: Fix broken link to version policy

docs/_chapters/170-versioning.md

@@ -113,7 +113,7 @@ This asymmetry creates the need for two version policies:
     -provider-policy :    ${range;[==,=+)}
     -consumer-policy :    ${range;[==,+)}
 
-The given values are the defaults. The value of the version policy will be used calculate the import based on the exported package. The `${range}` macro provides a convenient shortcut to do this using a version mask.
+The given values are the defaults. The value of the version policy will be used calculate the import based on the exported package. The [`${range}`](../macros/range.html) macro provides a convenient shortcut to do this using a version mask.
 
 For example, a bundle that implements the OSGi Event Admin service can use the following bnd file:
 
@@ -126,10 +126,14 @@ The resulting manifest would look like:
         Import-Package:  org.osgi.service.event; version="[1.1,2)", ...
         ...
 
-How does bnd know if a bundle is a provider or a consumer of a specific package? Well, the default is the consumer policy but this can be overridden with the `provide:=true` directive that works on the `Import-Package` clauses as well as on the `Export-Package` clauses. 
+How does bnd know if a bundle is a provider or a consumer of a specific package? 
+
+Well, the default is the consumer policy but this can be overridden with the `provide:=true` directive that works on the `Import-Package` clauses as well as on the `Export-Package` clauses.
 
 The `provide:` directive indicates to bnd that the given package contains API that is provided by this bundle. The (strongly) recommended way is to put the `provide:=true` directive on the `Export-Package` header, even if the package comes from another bundle. This way the bundle contains a copy of the package that is by default imported with the proper provider policy range.
 
+Also see [-consumerpolicy](../instructions/consumer_policy.html) and [-providerpolicy](../instructions/provider_policy.html).
+
 For example, an implementation of the OSGi Event Admin specification could use the following bnd file:
 
     bnd.bnd:

docs/_heads/import_package.md

@@ -11,7 +11,7 @@ For example:
     Import-Package: !org.apache.commons.log4j, com.acme.*,\
      com.foo.extra
 
-During processing, bnd will attempt to find the exported version of imported packages. If no version or version range is specified on the import instruction, the exported version will then be used though the micro part and the qualifier are dropped. That is, when the exporter is `1.2.3.build123`, then the import version will be 1.2. If a specific version (range) is specified, this will override any found version. This default an be overridden with the [-versionpolicy](../instructions/versionpolicy.html) instruction.
+During processing, bnd will attempt to find the exported version of imported packages. If no version or version range is specified on the import instruction, the exported version will then be used though the micro part and the qualifier are dropped. That is, when the exporter is `1.2.3.build123`, then the import version will be 1.2. If a specific version (range) is specified, this will override any found version. This default an be overridden with the [-consumerpolicy](../instructions/consumer_policy.html) or [-providerpolicy](../instructions/provider_policy.html) instruction (also see [Versioning](../chapters/170-versioning.html)).
 
 If an explicit version is given, then `${@}` can be used to substitute the found version in a range. In those cases, the [range](../macros/range.html) macro can be very useful to calculate ranges and drop specific parts of the version. For example:
 

docs/_macros/range.md

@@ -8,7 +8,7 @@ summary: Create a semantic version range out of a version using a mask to contro
 The `range` macro takes a version range mask/template and uses it calculate a range from a given version. The primary reason for the `${range}` macro is to be used in the [version policy][1]. With the version policy we have a version of an exported package and we need to calculate the range for that. The rules come from the [consumer][2] or [provider][3] policy. However, this policy can be overridden on the Import-Package header by specifying the version as a range macro:
 
 	Import-Package: com.example.myownpolicy; version="${range;[==,=+)}", *
-<foo ]>
+
 
 Since the version for the exported package is set as `${@}`, the macro will calculate the proper semantic range for a provider.