anchor.diff:  
   * we update the version in the `parent`
   * we perform any needed post-processing like a resolution of locks
  -* we commit and push the change. Voilà.
  +* we commit and push the change.
  +Voilà.
   
   If we put extra automation in the mix, you can define a perfectly valid auto versioning process.
   
  -This becomes more complex whenever having a new version of the `module` is not enough of a criteria to have it used. This may be a release which has not been qualified yet by extra quality processes (long running ones maybe).
  +This becomes more complex whenever having a new version of the `module` is not enough of a criteria to have it used.
  +This may be a release which has not been qualified yet by extra quality processes (long running ones maybe).
   
   That's where the concept of <<model,promotion>> in Ontrack can play a very important rule:
   
   * the `module` is promoted
   * this starts the following process:
  -  * Ontrack creates a pull request for the `parent` where the version of the `module` has been changed to the one being promoted
  -  * any required post processing is performed on this PR
  -  * when the PR is ready to be merged (with all its controls), it's merged automatically
  +* Ontrack creates a pull request for the `parent` where the version of the `module` has been changed to the one being promoted
  +* any required post processing is performed on this PR
  +* when the PR is ready to be merged (with all its controls), it's merged automatically
   
   Result:
   
  
positive.code: * `postProcessing` - ID of the post-processing mechanism
  * `postProcessingConfig` - configuration for the post-processing mechanism
  
  As of now, only two post-processing mechanisms are supported. See the sections below for their respective configurations.
  
  [[auto-versioning-post-processing-github]]
  ===== GitHub post-processing
  
negative.code: #root.^[kind == 'Deployment' and metadata.name == 'my-app'].spec.template.spec.containers.^[name == 'component'].image
  ----
  
  See the https://docs.spring.io/spring/docs/4.3.25.RELEASE/spring-framework-reference/htmlsingle/#expressions[Spring Expression Language] reference for a complete reference but this expression already illustrates some key points:
  
  * `#root` refers to the "root object", used to evaluate the expression, in our case, the list of YAML "documents", separated by `---`
  * `.^[<filter>]` is an operator for a list, evaluating the given filter for each element until one element is found.
  Only the found element is returned.
  * `.name` returns the value of the `name` property on an object
  * literal strings are using single quotes, for example: `'Deployment'`
  
  If `property` is set to the expression mentioned above, the value being returned will be
  `repo/component:0.1.1`.
  However, we want to use `0.1.1`only.
  
  For this purpose, you need to specify also the `propertyRegex` and set it, for this example to:
  
  