Remove the concept of named, identifiable runs.

StarBoss is meant for building things checked into the repo It is also designed
around repeatable builds. So it makes the assumption that running a build step
for a specific version of a project will always result in the same output. So
runs are identified by the project, build step, and version.

README.md

@@ -8,7 +8,6 @@
 * Configuration is two-part. Pipeline, step, and artifact definition are part
   of the project configuration (.strawboss.json? yaml?). Environment
   configuration lives on the strawboss server (supplies DB info, etc.).
-* REST API?
 * Step execution happens within the root directory of a fresh copy of the repo.
   Commit identifiers (hash/ref/etc.) are supplied when a build is triggered and
   the fresh copy is checked out at that reference.
@@ -114,7 +113,12 @@ object. The top level keys are:
 
 * `versionCmd` *(optional)*: a command to be run in a shell (`sh`-compatible)
   that is expected to print the current version of the project on `stdout`.
-  *(defaults to `git describe --tags --always`)*.
+  It is important to note that if you supply a verion command it should provide
+  a unique result for every commit in the repository. StrawBoss is built around
+  the assumptions that builds are repeatable and that every buildable point has
+  a unique version id. This is the reason that StrawBoss does not create uniue
+  IDs for individual builds. The combination of project name, build step, and
+  version *is* the build ID. *(defaults to `git describe --tags --always`)*.
 
 ####  Step Definition
 
@@ -268,7 +272,7 @@ asset. To avoid `git` complications it is stored as a Gzipped TAR file and
 unpacked to a temporary directory as part of the functional test process.
 
 As the functional tests are more time-consuming and intensive, they are
-expected to bu run when performing a build.
+expected to be run when performing a build.
 
 To run the functional tests, use the `functest` nimble task: