Merge pull request #2824 from dnephin/docs_version_is_a_string

Update docs for version being a string

docs/compose-file.md

@@ -183,7 +183,7 @@ Express dependency between services, which has two effects:
 
 Simple example:
 
-    version: 2
+    version: '2'
     services:
       web:
         build: .
@@ -658,7 +658,7 @@ In the example below, instead of attemping to create a volume called
 `[projectname]_data`, Compose will look for an existing volume simply
 called `data` and mount it into the `db` service's containers.
 
-    version: 2
+    version: '2'
 
     services:
       db:
@@ -748,7 +748,7 @@ attemping to create a network called `[projectname]_outside`, Compose will
 look for an existing network simply called `outside` and connect the `proxy`
 service's containers to it.
 
-    version: 2
+    version: '2'
 
     services:
       proxy:
@@ -780,7 +780,7 @@ There are two versions of the Compose file format:
 
 - Version 1, the legacy format. This is specified by omitting a `version` key at
   the root of the YAML.
-- Version 2, the recommended format. This is specified with a `version: 2` entry
+- Version 2, the recommended format. This is specified with a `version: '2'` entry
   at the root of the YAML.
 
 To move your project from version 1 to 2, see the [Upgrading](#upgrading)
@@ -842,7 +842,7 @@ under the `networks` key.
 
 Simple example:
 
-    version: 2
+    version: '2'
     services:
       web:
         build: .
@@ -855,7 +855,7 @@ Simple example:
 
 A more extended example, defining volumes and networks:
 
-    version: 2
+    version: '2'
     services:
       web:
         build: .
@@ -887,7 +887,7 @@ A more extended example, defining volumes and networks:
 In the majority of cases, moving from version 1 to 2 is a very simple process:
 
 1. Indent the whole file by one level and put a `services:` key at the top.
-2. Add a `version: 2` line at the top of the file.
+2. Add a `version: '2'` line at the top of the file.
 
 It's more complicated if you're using particular configuration features:
 
@@ -950,7 +950,7 @@ It's more complicated if you're using particular configuration features:
     named volume called `data`, you must declare a `data` volume in your
     top-level `volumes` section. The whole file might look like this:
 
-        version: 2
+        version: '2'
         services:
           db:
             image: postgres

docs/networking.md

@@ -28,7 +28,7 @@ identical to the container name.
 
 For example, suppose your app is in a directory called `myapp`, and your `docker-compose.yml` looks like this:
 
-    version: 2
+    version: '2'
 
     services:
       web:
@@ -63,7 +63,7 @@ If any containers have connections open to the old container, they will be close
 
 Links allow you to define extra aliases by which a service is reachable from another service. They are not required to enable services to communicate - by default, any service can reach any other service at that service's name. In the following example, `db` is reachable from `web` at the hostnames `db` and `database`:
 
-    version: 2
+    version: '2'
     services:
       web:
         build: .
@@ -86,7 +86,7 @@ Each service can specify what networks to connect to with the *service-level* `n
 
 Here's an example Compose file defining two custom networks. The `proxy` service is isolated from the `db` service, because they do not share a network in common - only `app` can talk to both.
 
-    version: 2
+    version: '2'
 
     services:
       proxy:
@@ -123,7 +123,7 @@ For full details of the network configuration options available, see the followi
 
 Instead of (or as well as) specifying your own networks, you can also change the settings of the app-wide default network by defining an entry under `networks` named `default`:
 
-    version: 2
+    version: '2'
 
     services:
       web:

docs/overview.md

@@ -32,7 +32,7 @@ they can be run together in an isolated environment.
 
 A `docker-compose.yml` looks like this:
 
-    version: 2
+    version: '2'
     services:
       web:
         build: .