Use <major>.<minor> api version syntax to match PR #19

Signed-off-by: Emily Casey <ecasey@pivotal.io>

text/0000-lifecycle-descriptor.md

@@ -25,24 +25,27 @@ Lifecycle can include a `lifecycle.toml` at it's root. Initially, the only suppo
 
 ```toml
 [api]
- platform = "1"
- buildpack = "1"
+ platform = "<major>.<minor>"
+ buildpack = "<major>.<minor>"
 
 [lifecycle]
-  version = "v0.4.0"
+  version = "<major>.<minor>.<patch>"
 ```
 
+The format of a api version would be <major>.<minor> or <major> (with a minor of 0 implied). A change to the major version of an API would indicate a non-backwards-compatible change, while a change to the minor version would indicate availability of one or more opt-in features.
+
 When `lifeycle.toml` exists but either of the `api.x` fields is omitted, `pack` will be assume that the lifecycle implements the latest API known to that version of `pack`. When `lifecycle.toml` is omitted, `pack` will initially warn users and assume the lifecycle implements the oldest known api version, for backwards compatibility. Eventually `pack` may require the presence of `lifecycle.toml`.
 
 # How it Works
 [how-it-works]: #how-it-works
 
 When `pack create-builder` creates a builder. The lifecycle API versions will be added to the `io.buildpacks.builder.metadata` label.
 
+Example:
 ```json
 {
 ...
-"lifecycle": {"version":  "v0.4.0", "api": {"platform":  "1", "buildpack":  "1"}}
+"lifecycle": {"version":  "v0.4.0", "api": {"platform":  "1.0", "buildpack":  "1.1"}}
 }
 ```