anchor.diff:  $ git push origin --delete springCloudBuildRelease
   ```
   
  -==== Releasing a release train
  +==== Releasing a Release Train
   
   We call a release train a `meta-release`. In order to perform one, you need to:
   
  -- in your BOM containing project (e.g. `spring-cloud-release` you have to have a branch, where you store properties with versions of your projects. E.g. the branch name can be https://github.com/spring-cloud/spring-cloud-release/tree/jenkins-releaser-config[jenkins-releaser-config]).
  +. In your project (which must contain a BOM, such as `spring-cloud-release`) you have to have a branch, where you store properties with versions of your projects. For example, the branch name can be https://github.com/spring-cloud/spring-cloud-release/tree/jenkins-releaser-config[jenkins-releaser-config]). The folloiwng example shows how to do so:
   ```bash
   $ git clone git@github.com:spring-cloud/spring-cloud-release.git
   $ cd spring-cloud-release
   $ git checkout jenkins-releaser-config
   ```
  -- create a file that will contain all properties for a given release train. The name of the release train should be lowercase and dots should be converted to underscores. E.g. for the `Greenwich.SR2` release train we need to have `greenwich_sr2.properties` file.
  +. Create a file that contains all properties for a given release train. The name of the release train should be lowercase, and dots should be converted to underscores. For example, for the `Greenwich.SR2` release train we need to have a file named  `greenwich_sr2.properties`. The following example shows how to do so:
   ```bash
   $ touch greenwich_sr2.properties
   ```
  -- We need to update the file with all versions for the release train. The properties file contains an *ordered* list of `releaser.fixed-versions[project-name]=project-version` entries.
  +. We need to update the file with all versions for the release train. The properties file contains an *ordered* list of `releaser.fixed-versions[project-name]=project-version` entries, as the following listing shows:
   ```bash
   $ echo "releaser.fixed-versions[spring-boot]=2.1.5.RELEASE
   releaser.fixed-versions[spring-cloud-build]=2.1.5.RELEASE
  
positive.code: # to store the pass in the agent
  $ ssh-add ~/.ssh/id_rsa
  ----
  
  before running the app
  
negative.code: $ java -jar target/spring-cloud-release-tools-spring-1.0.0.M1.jar --releaser.working-dir=/path/to/project/root
  ----
  
  === Releasing through Jenkins
  
  NOTE: Whenever a release process is broken, Jenkins marks it with a red ball and breaks the build. Whenever a post-release action went wrong but the release is successful, Jenkins marks the build with a yellow ball and marks the build as unstable.
  
  ==== Releasing a Single Project
  
  Let us assume that we are to release `spring-cloud-build` project. We need to do the following steps:
  
  . Create a branch (for example, `springCloudBuildRelease`) in a project that contains a BOM (for example, https://github.com/spring-cloud/spring-cloud-release/[spring-cloud-release]). The following example shows how to do so:
  ```bash
  $ git clone git@github.com:spring-cloud/spring-cloud-release.git
  $ cd spring-cloud-release
  $ git checkout -b springCloudBuildRelease
  ```
  . Update *all* versions as if you were doing a release train. We need to update the project's versions, Boot version, and dependencies versions, too. Let us assume that we will eventually be doing a release train for the `Hoxton.M1` release, Spring Boot to the latest available one, and `spring-cloud-commons` to `1.2.3.BUILD-SNAPSHOT`. The following example shows how to do so:
  ```bash
  // setting the release train value
  $ ./mvnw versions:set -DnewVersion=Hoxton.M1 -DgenerateBackupPoms=false -DprocessAllModules=true
  