anchor.diff:  
   ### <a id="..."></a> Upload blobs ###
   
  -  `bosh upload blobs`
  +You are ready to do a final release except for one thing:
  +your latest dev release depends on locally-stored blobs.
  +
  +You remedy this by uploading your blobs to a public blobstore:
  +
  +`bosh upload blobs`
  +
  +### <a id="..."></a> Commit ###
  +
  +You have run the `bosh upload blobs` command so the `blobs` file now contains names and keys.
  +
  +This is a good time to commit.
   
   ### <a id="..."></a> Release ###
   
  -  `bosh release --final`
  -
  -
  -## <a id="..."></a> Test the Final Release  ##
  -
  -
  -
  -
  -
  -
  -
  +Run:
  +
  +`bosh release --final`
  +
  +BOSH prompts you for a release name, and assigns a whole-number version to the release.
  +
  +## <a id="..."></a> Deploy the Final Release  ##
  +
  +Run:
  +
  +`bosh deploy`
  +
  
positive.code:   `bosh generate package libyaml_0.1.4`
  
  You now have package skeletons for all the dependencies in your release.
  Later on, you will flesh out the skeletons to make them usable packages.
  
  ## <a id="..."></a> Add Blobs Locally ##
  
  When creating a release, you use git for your source code.
  Git is not well-suited to dealing with large binaries, however.
  For this reason, you add blobs to a local blobstore while creating
  dev releases.
  
  Before you create a final release, you typically upload the blobs to a public blobstore.
  
  ### <a id="..."></a> Decide what blobs to add ###
  
  * running `bosh add blob` now would fail with an error
  
  ### <a id="..."></a> Create a local blobstore  ###
  
  * in `config` folder: `final.yml` and `private.yml`
  
  ### <a id="..."></a> Add blobs to blobstore ###
  
  
negative.code: 
  ## <a id="..."></a> Test the Dev Release  ##
  
  What tests to run depends on the software you are releasing.
  
  
  
  * Debug primer: log in on VM, etc.
  * If your release fails any of these tests, fix and do a new dev release.
  
  