love for distribution doc

distribution.md

@@ -15,30 +15,32 @@ e.g. `v1.0.2`
 * **Release Candidate**: not ready for public use, still testing. must have a
 `-rc*` suffix. e.g. `v1.0.2-rc` or `v1.0.2-rc.4`
 
+---
+
 1. **Update the version of step/cli**
 
-    ```
+   <pre><code>
-    $ dep ensure -update github.com/smallstep/cli
+   <b>$ dep ensure -update github.com/smallstep/cli</b>
-    ```
+   </code></pre>
 
 2. **Commit all changes.**
 
     Make sure that the local checkout is up to date with the remote origin and
     that all local changes have been pushed.
 
-    ```
+    <pre><code>
-    $ git pull --rebase origin master
+    <b>$ git pull --rebase origin master</b>
-    $ git push
+    <b>$ git push</b>
-    ```
+    </code></pre>
 
 3. **Tag it!**
 
     1. **Find the most recent tag.**
 
-        ```
+        <pre><code>
-        $ git fetch --tags
+        <b>$ git fetch --tags</b>
-        $ git tag
+        <b>$ git tag</b>
-        ```
+        </code></pre>
 
         The new tag needs to be the logical successor of the most recent existing tag.
         See [versioning](#versioning) section for more information on version numbers.
@@ -47,14 +49,14 @@ e.g. `v1.0.2`
 
         Is the new release a *release candidate* or a *standard release*?
 
-        1. Release Candidate
+        1. **Release Candidate**
 
             If the most recent tag is a standard release, say `v1.0.2`, then the version
             of the next release candidate should be `v1.0.3-rc.1`. If the most recent tag
             is a release candidate, say `v1.0.2-rc.3`, then the version of the next
             release candidate should be `v1.0.2-rc.4`.
 
-        2. Standard Release
+        2. **Standard Release**
 
             If the most recent tag is a standard release, say `v1.0.2`, then the version
             of the next standard release should be `v1.0.3`. If the most recent tag
@@ -64,21 +66,25 @@ e.g. `v1.0.2`
 
     3. **Create a local tag.**
 
-        ```
+        <pre><code>
-        $ git tag v1.0.3   # standard release
+        # standard release
+        <b>$ git tag v1.0.3</b>
         ...or
-        $ git tag v1.0.3-rc.1  # release candidate
+        # release candidate
-        ```
+        <b>$ git tag v1.0.3-rc.1</b>
+        </code></pre>
 
     4. **Push the new tag to the remote origin.**
 
-        ```
+        <pre><code>
-        $ git push origin tag v1.0.3   # standard release
+        # standard release
+        <b>$ git push origin tag v1.0.3</b>
         ...or
-        $ git push origin tag v1.0.3-rc.1  # release candidate
+        # release candidate
-        ```
+        <b>$ git push origin tag v1.0.3-rc.1</b>
+        </code></pre>
 
-4. Check the build status at
+4. **Check the build status at**
 [Travis-CI](https://travis-ci.com/smallstep/certificates/builds/).
 
     Travis will begin by verifying that there are no compilation or linting errors
@@ -93,21 +99,21 @@ e.g. `v1.0.2`
     * **step-certificates_1.0.3_darwin_amd64.tar.gz**: tarball containing a statically compiled darwin binary.
     * **step-certificates.tar.gz**: tarball containing a git archive of the full repo.
 
-6. **Update the AUR Arch Linux package**
+5. **Update the AUR Arch Linux package**
 
     > **NOTE**: if you plan to release `cli` next then you can skip this step.
 
-    ```
+    <pre><code>
-    $ cd archlinux
+    <b>$ cd archlinux</b>
 
     # Get up to date...
-    $ git pull origin master
+    <b>$ git pull origin master</b>
-    $ make
+    <b>$ make</b>
 
-    $ ./update --ca v1.0.3
+    <b>$ ./update --ca v1.0.3</b>
-    ```
+    </code></pre>
 
-7. **Update the Helm packages**
+6. **Update the Helm packages**
 
     > **NOTE**: This is an optional step, only necessary if we want to release a
     > new helm package.
@@ -125,9 +131,9 @@ e.g. `v1.0.2`
 
     Then create the step-certificates package running:
 
-    ```sh
+    <pre><code>
-    $ helm package ./step-certificates
+    <b>$ helm package ./step-certificates</b>
-    ```
+    </code></pre>
 
     A new file like `step-certificates-<version>.tgz` will be created.
     Now commit and push your changes (don't commit the tarball) to the master
@@ -136,15 +142,15 @@ e.g. `v1.0.2`
     Next checkout the `gh-pages` branch. `git add` the new tar-ball and update
     the index.yaml using the `helm repo index` command:
 
-    ```sh
+    <pre><code>
-    $ git checkout gh-pages
+    <b>$ git checkout gh-pages</b>
-    $ git add "step-certificates-<version>.tgz"
+    <b>$ git add "step-certificates-<version>.tgz"</b>
-    $ helm repo index --merge index.yaml --url https://smallstep.github.io/helm-charts/ .
+    <b>$ helm repo index --merge index.yaml --url https://smallstep.github.io/helm-charts/ .</b>
-    $ git commit -a -m "Add package for step-certificates <appVersion>"
+    <b>$ git commit -a -m "Add package for step-certificates <appVersion>"</b>
-    $ git push origin gh-pages
+    <b>$ git push origin gh-pages</b>
-    ```
+    </code></pre>
 
-*All Done!*
+***All Done!***
 
 ## Versioning