anchor.diff:  - use Hypermedia, links and do not version your API by any means
   - pass versions through headers / urls
   
  -I will not try to answer a question which approach is better. Whatever suit your needs and allows you to generate
  +I will not try to answer a question which approach is better. Whatever suits your needs and allows you to generate
   business value should be picked.
   
   Let's assume that you do version your API. In that case you should provide as many contracts as many versions you support.
  -You can create a subfolder for every version or append it to th contract name - whatever suits you more.
  +You can create a subfolder for every version or append it to the contract name - whatever suits you more.
   
   ==== JAR versioning
   
  
positive.code:         └── contracts.xml
  ----
  
  As you can see the under the slash-delimited groupid `/` artifact id folder (`com/example/server`) you have
  expectations of the 3 consumers (`client1`, `client2` and `client3`). Expectations are the standard Groovy DSL
  contract files as described throughout this documentation. This repository has to produce a JAR file that maps
  one to one to the contents of the repo.
  
negative.code: 
  Yes! With version 1.2.0 we've added such a possibility. It's enough to call `file(...)` method in the
  DSL and provide a path relative to where the contract lays.
  If you're using YAML just use the `bodyFromFile` property.
  