v0.2.0

Author: fgrehm

CHANGELOG.md

@@ -1,4 +1,4 @@
-## [0.2.0](https://github.com/fgrehm/devstep/compare/v0.1.0...next) (unreleased)
+## [0.2.0](https://github.com/fgrehm/devstep/compare/v0.1.0...v0.2.0) (2014-09-24)
 
 BREAKING CHANGES:
 

docs/cli/installation.md

@@ -10,7 +10,7 @@ This one liner can handle it for you assuming that `$HOME/bin` is available
 on your `PATH`:
 
 ```sh
-L=$HOME/bin/devstep && curl -sL https://github.com/fgrehm/devstep-cli/raw/v0.1.0/devstep > $L && chmod +x $L
+L=$HOME/bin/devstep && curl -sL https://github.com/fgrehm/devstep-cli/releases/download/v0.1.0/devstep > $L && chmod +x $L
 ```
 
 Please note that the CLI is currently limited to connecting to a local `/var/run/docker.sock`

docs/cli/plugins.md

@@ -13,7 +13,7 @@ that a plugin folder should have a `plugin.js` file.
 
 The current functionality is very rudimentary and is likely to be changed so right
 now it is best explained by the [squid3-ssl proxy](https://github.com/fgrehm/devstep-squid3-ssl)
-plugin source which is currently the plugin available:
+plugin source which is currently the only plugin available:
 
 ```js
 // `_currentPluginPath` is the host path where the JavaScript file is located

docs/cli/tips.md

@@ -30,7 +30,7 @@ to make it persistent, just set it to a folder that doesn't have that behavior
 (like some dir under your `$HOME`).
 
 For example, you can add the line below to your `$HOME/devstep.yml` to configure
-cached packages to be kept on `$HOME/devstep-cache`:
+cached packages to be kept on `$HOME/devstep/cache`:
 
 ```yaml
 cache_dir: '{{env "HOME"}}/devstep/cache'

docs/getting-started.md

@@ -6,7 +6,7 @@ on top of the provided images from `Dockerfile`s.
 
 Regardless of the flavor you choose, it is a good idea to `docker pull fgrehm/devstep:v0.2.0`
 before creating your first container / image for a better user experience. Docker
-will download that image as needed when using `Dockerfile`s but the CLI isn't.
+will download that image as needed when using `Dockerfile`s but the Devstep CLI won't.
 
 ## Sanity check
 ---------------
@@ -40,7 +40,7 @@ line to your `~/devstep.yml` so that the image is used as a source for your proj
 To install the CLI, you can run the one liner below and read on for more:
 
 ```sh
-L=$HOME/bin/devstep && curl -sL https://github.com/fgrehm/devstep-cli/raw/v0.1.0/devstep > $L && chmod +x $L
+L=$HOME/bin/devstep && curl -sL https://github.com/fgrehm/devstep-cli/releases/download/v0.1.0/devstep > $L && chmod +x $L
 ```
 
 _The snippet above assumes `$HOME/bin` is on your PATH, change `$HOME/bin` to
@@ -62,7 +62,7 @@ When you are done hacking, just `exit` the container and it will be "garbage
 collected" (aka `docker rm`ed) and no project specific dependencies will be kept
 on your machine.
 
-### Taking snapshot of the environment to reduce startup time
+### Taking snapshots of the environment to reduce startup time
 
 Building an environment from scratch all the time you need to work on a project
 is not very productive. To alleviate that pain you can use the `devstep build`
@@ -126,24 +126,6 @@ have to worry about that.
 For example, installing and configuring [memcached](http://memcached.org/) inside
 the container is a matter of running `configure-addons memcached` from there.
 
-### Binstubs
-
-commands:
-# This can be run with `devstep run server`
-server:
-cmd: ["rails", "server"]
-# Here you can use some of the configs described above
-publish: ["3000:3000"]
-volumes:
-- '{{env "HOME"}}/certs/some-certificate.crt:/.devstep/some-certificate.crt'
-- '{{env "HOME"}}/projects/some-gem-sources:/.devstep/some-gem-sources'
-links:
-- 'redis:redis'
-environment:
-RAILS_ENV: "hacking"
-ruby:
-# No custom options, used only for generating binstubs
-
 ### Bootstrapping a new project (AKA solving the chicken or the egg problem)
 
 Assuming you are willing to use Docker / Devstep to avoid cluttering your machine

docs/introduction.md

@@ -1,8 +1,6 @@
 # Introduction
 --------------
 
-# TODO: Note that we are using cedarish:cedar14
-
 Have you ever deployed an app to a platform like Heroku? How awesome it is to
 `git push` some code and see it running without worrying about the infrastructure
 it is going to run on? Now imagine that idea applied to any type of project,
@@ -38,17 +36,17 @@ extracted inside the container.
 ## Usage
 
 Devstep can be used to build development environments in at least two different
-ways: from the provided Bash CLI or from `Dockerfile`s. To run the images built,
+ways: from the provided Golang CLI or from `Dockerfile`s. To run the images built,
 you can use the provided `devstep hack` command, use other tools (like [Fig](http://orchardup.github.io/fig/))
 or just `docker run` them by hand.
 
 
 ## What's included on the base [Docker image](https://registry.hub.docker.com/u/fgrehm/devstep/)?
 
-That image is based on [`progrium/cedarish`](https://github.com/progrium/cedarish),
+That image is based on [`progrium/cedarish:cedar14`](https://github.com/progrium/cedarish),
 so everything that gets installed by it will be available for `fgrehm/devstep` images.
 
-On top of `progrium/cedarish`, we:
+On top of `progrium/cedarish:cedar14`, we:
 
 * Create a `developer` user to avoid using `root` and creating files with wrong permissions during development.
 * Install some extra devel packages (like `libyaml-dev`) and other "nice to have"