anchor.diff:  
     `bosh generate package ruby_1.9.3`
   
  -* correct name in the spec (now is ruby_1.9.3 not plain ruby)
  -
   Next, create packages for package dependencies.
   The only package dependency in our example is that the Ruby
   package depends on the YAML library.
  
positive.code: 
  Suppose you want to create a BOSH release of an application that you have developed.
  
  BOSH releases are created using an iterative workflow:
  
  1. Develop the application.
  1. Create a **dev release**.
    * BOSH bumps the release number by a "dot".
  1. Deploy the **dev release** to your test environment.
  1. Test the **dev release**.
  Is it ready for final release?
      * If the answer is no, begin the cycle again.
      * If the answer is yes, continue.
  1. Create a **final release**
    * BOSH bumps the release number by whole number.
  
  The BOSH release workflow embodies some principles intended to make BOSH releases
  optimally useful.
  Among these principles are the following:
  
  * BOSH releases do not necessarily depend on the internet.
  * BOSH release don't add blobs to GitHub.
  * 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 related pieces of software.
  For example, such a collection might include a few MySQL nodes along with a dashboard app.
  
  In a BOSH release, each of these pieces of software is a _job_.
  You also need to know the conception of _packages_, _src_, and _blobs_ that apply in
  the world of BOSH releases.
  
  * **jobs** describe pieces of a service
  * **packages** provide source code and dependencies to jobs
  * **src** provide non-binary files to packages
  * **blobs** provides binaries not checked into git
  
  Where to draw the line between what should and should not be included in a release
  is a judgment call when you are dealing with more complex examples of distributed software.
  
  
  
  ### <a id="..."></a> About this tutorial ###
  
  This tutorial walks you through creating a dev release and then a final release
  that contains a single job, namely a Sinatra app called `ardo`.
  
  ## <a id="..."></a> Create the Release Directory ##
  
  Make the release directory:
  
    `bosh init release --git`
  
  * `cd` into it.
  * All commands in the example are run from here.
  
  ## <a id="..."></a> Create the Job Skeleton ##
  
  This command generates a job _skeleton_, meaning ...
  
    `bosh generate job ardo-web`
  
  ### <a id="..."></a> Create a control script for the job  ###
  
  * In the spec for the job, create a template for the control script.
  * Templates are `erb` files, so this one is `ctl.erb.`
  * The spec shows the file that template will become in the actual app at compile time:
    `ctl.erb: bin/ctl`
  * Create start and stop scripts and save them as `ctl.erb.`
  * Some real development work here, maybe to iterate on later.
  * `set -e -x`
  
  ### <a id="..."></a>   ###
  
  * In the packages block of the spec, add a line describing a package for the job.
  * The actual package does not exist yet.
  
  ### <a id="..."></a> Commit ###
  
  ## <a id="..."></a> Create Dependency Package Skeletons ##
  
  A BOSH release contains one package for each of its jobs,
  and additional packages, one for each dependencies.
  To see clearly what packages you need to create,
  start by making a dependency graph.
  
  
negative.code: 
  ### <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.
  
  Three rules govern these dependencies:
  
  * Jobs never depend on other jobs.
  * Jobs can depend on packages.
  * Packages can depend on other packages.
  
  Whether your release works or not depends on your correctly understanding the dependencies
  between its jobs and packages.
  Creating a dependency graph helps you clarify this understanding, and provides an essential
  reference as you add elements to the release.
  
  Go through any scripts you have created and note the files cited by each script.
  The names of these files must be added to the `packages` block of the job spec.
  In our example, they are `ardo_web` and `ruby_1.9.3`.
  
  Edit the `packages` block of the job spec to show the files cited by the control script:
  
  ~~~yaml
  packages:
  - ardo_web
  - ruby_1.9.3
  ~~~
  
  The dependency graph for `ardo-release` looks like this:
  
  _insert illustration_
  
  ### <a id="..."></a> Add package skeletons ###
  
  