anchor.diff:  Be aware that if you followed the recommended practice of using the `--git` option with
   `bosh init release`, the correct `.gitignore` file has been automatically created for you.
   
  -## <a id="..."></a> Create Dependency Package Skeletons ##
  -
  -A BOSH release contains one package for each of its jobs,
  -and additional packages, one for each dependency.
  -To see clearly what packages you need to create,
  -start by making a dependency graph.
  -
  -Then take a bottom-up approach, creating package skeletons
  -for dependencies, while leaving the job package for later.
  -
  -### <a id="..."></a> Make a dependency graph ###
  +## <a id="..."></a> Make a dependency graph ##
   
   There are two kinds of dependencies in a BOSH release:
   
  -* The **job dependency**, for example, the `ardo_web` job depends on Ruby.
  -* The **package dependency**, for example, the Ruby package in your release depends on the YAML library.
  +* The **runtime dependency**, where a job depends on a package at runtime.
  +For example, the `ardo_web` job depends on Ruby.
  +* The **compile-time dependency**, where a package depends on another package at compile time.
  +For example, Ruby depends on the YAML library.
   
   Three rules govern these dependencies:
   
  
positive.code: 1. Create a **final release**.
    * BOSH bumps the release number by whole number.
  
  Beside the workflow, this tutorial explains principles to
  keep in mind when creating BOSH releases:
  
  * BOSH releases package up all dependencies.
  * BOSH releases do not add blobs to a git repository.
  * BOSH releases remain buildable for a long time.
  * BOSH releases do not necessarily depend on the internet.
  
  * Using underscores in filenames is the BOSH way.
  * Commenting your code to facilitate debugging is the BOSH way.
  
  ## <a id="..."></a> Decide What to Release ##
  
  Some releases contain a single app.
  Others are collections of the pieces of software that together form a particular service.
  For example, such a collection might include a few MySQL nodes along with a dashboard app.
  You might think of each of these pieces of software as an area of functionality, or a feature.
  In a BOSH release, each such piece is a _job_.
  
  In a BOSH release:
  
  * **jobs** describe pieces of a service.
  * **packages** provide source code and dependencies to jobs.
  * **src** provides non-binary files to packages.
  * **blobs** provides binaries not checked into a Git repository.
  
  Creating a release entails several judgment calls: what to include, how to structure it, and how to split up jobs and packages.
  
  
negative.code: 
  Observe how these conventions are followed in the examples.
  
  _add examples inline_
  
  ### <a id="..."></a> Add Blobs Locally ###
  
  When creating a release, use Git for your source code.
  Since Git is not well-suited to dealing with large binaries,
  