Fix the various places where version 2.1 was not represented in sampl…

…es (#54)
CircleCI-Public · Aug 26, 2018 · 0d39520 · 0d39520
1 parent 54dd8aa
commit 0d39520
Show file tree

Hide file tree

Showing 6 changed files with 12 additions and 17 deletions.
diff --git a/docs/commands.md b/docs/commands.md
@@ -83,13 +83,12 @@ commands:
 The above could be invoked in `config.yml` as:
 
 ```yaml
-version: 2
+version: 2.1
 
 orbs:
   s3tools: circleci/s3@1
 
 workflows:
-  version: 2
   build-test-deploy:
     jobs:
       - deploy2s3:

diff --git a/docs/conditional-steps.md b/docs/conditional-steps.md
@@ -43,7 +43,7 @@ jobs:
 
 ```yaml
 # inside config.yml
-version: 2
+version: 2.1
 
 orbs:
   myorb: mynamespace/myorb@1.0.1

diff --git a/docs/executors.md b/docs/executors.md
@@ -21,7 +21,7 @@ An executor definition includes the subset of the children keys of a `job` decla
 A simple example of using an executor:
 
 ```yaml
-version: 2
+version: 2.1
 executors:
   my-executor:
     docker:
@@ -201,7 +201,7 @@ Parameters in executors can be of the type `string` or `boolean`. Default values
 
 **Example build configuration using a parameterized executor**
 ```yaml
-version: 2
+version: 2.1
 
 executors:
   python:
@@ -226,7 +226,7 @@ jobs:
 
 **The above would resolve to:**
 ```yaml
-version: 2
+version: 2.1
 jobs:
   build:
     steps: []

diff --git a/docs/jobs.md b/docs/jobs.md
@@ -15,7 +15,7 @@ A user must invoke jobs in the workflows stanza of `config.yml`, passing any nec
 Example of defining and invoking a parameterized job in a `config.yml`:
 
 ```yaml
-version: 2
+version: 2.1
 
 jobs:
   sayhello:
@@ -30,7 +30,6 @@ jobs:
       - echo "Hello << parameters.saywhat >>"
 
 workflows:
-  version: 2
   build:
     jobs:
       - sayhello:
@@ -67,10 +66,10 @@ commands:
 **Config leveraging hello-orb**
 ```yaml
 # config.yml
+version: 2.1
 orbs:
   hello-orb: somenamespace/hello-orb@volatile
 workflows:
-  version: 2
   build:
     jobs:
       - hello-orb/sayhello:
@@ -82,7 +81,7 @@ workflows:
 Parameters are in-scope only within the job or command that defined them. If you want a job or command to pass its parameters to a command it invokes, they must be passed explicitly.
 
 ```yaml
-version: 2
+version: 2.1
 
 jobs:
   sayhello:
@@ -108,7 +107,6 @@ commands:
       - echo "<< parameters.saywhat >>"
 
 workflows:
-  version: 2
   build:
     jobs:
       - sayhello:
@@ -124,8 +122,8 @@ A single configuration may invoke a job many times. At configuration processing
 >NOTE: The user must explicitly name repeat jobs when a repeat job should be upstream of another job in a workflow (ie: if the job is used under the `requires` key of a job invocation in a workflow you will need to name it).
 
 ```yaml
+version: 2.1
 workflows:
-  version: 2
   build:
     jobs:
       - loadsay

diff --git a/docs/pre-and-post-steps.md b/docs/pre-and-post-steps.md
@@ -39,11 +39,10 @@ jobs:
 Then an orb user could use the job as follows:
 ```yaml
 # config.yml
-version: 2
+version: 2.1
 orbs:
   foo: somenamespace/foo@1.2
 workflows:
-  version: 2
   build:
     jobs:
       - foo/bar:
@@ -58,7 +57,7 @@ workflows:
 The resulting configuration would look like this:
 
 ```yaml
-version: 2
+version: 2.1
 jobs:
   foo/bar:
     machine: true
@@ -73,7 +72,6 @@ jobs:
       - run:
           command: echo "upload artifact to s3"
 workflows:
-  version: 2
   build:
     jobs:
       - foo/bar

diff --git a/docs/whats-new.md b/docs/whats-new.md
@@ -11,7 +11,7 @@
 Using an orb in your build configuration might look something like:
 
 ```yaml
-version: 2
+version: 2.1
 orbs:
   s3: circleci/aws-s3@1