Clarify Release Process in CLI docs (#182)

* Clarify how `pear stage` generates key & replicates staged changes

* Clarify how `pear seed` distributes the channel / link of an app

* Add brief description of release pointer to `pear release` doc

* Add note about rolling back a release

* Fix grammar & add more details to why staging can propagate w/o seeding

* Tweak staging description to make update to version explicit

* Add second dump-based strategy for rolling back a release

reference/pear/cli.md

@@ -40,11 +40,12 @@ Alias for: `pear run --dev <dir>`
 
 Synchronize local changes to channel or key.
 
-Channel name must be specified on first stage,
+Channel name must be specified on first stage, in order to generate the initial key. This key is unique to the combination of the application name, the channel name and the device's unique corestore key. This means the key does not change after the first time the channel is staged.
-in order to generate the initial key.
 
 Outputs diff information and project link.
 
+Each time new changes are staged, the length for the channel / link will update, hence updating the version. This change can be replicated to any peer who know the link and is connected. If they run `pear info <link>`, they will see the `length` update even if the application is not being seeded. Connections can potentially linger after seeding an application but will eventually close.
+
 ```
   --json                      Newline delimited JSON output
   --dry-run|-d                Execute a stage without writing
@@ -61,6 +62,8 @@ Seed project or reseed key.
 
 Specify channel or link to seed a project or a remote link to reseed.
 
+Seeding will sparsely replicate the application. This means the entire history of the channel or link is available, but most likely only the most recent version will be replicated. For more info, read ["Lazy loading large files & sparse replication"](./guides/sharing-a-pear-app#lazy-loading-large-files-and-sparse-replication) section in the "Sharing a Pear Application" guide.
+
 ```
   --json                    Newline delimited JSON output
   --name                    Advanced. Override app name
@@ -123,7 +126,7 @@ Set production release version.
 
 Set the release pointer against a version (default latest).
 
-Use this to indicate production release points.
+Use this to indicate production release points. Once a channel or link has been released (setting a pointer for a given version) running the application (via `pear run <link>`) will load the application at the released version even if more changes were staged.
 
 ```
   --json                   Newline delimited JSON output
@@ -131,6 +134,23 @@ Use this to indicate production release points.
   --help|-h                Show help
 ```
 
+### Release rollbacks
+
+Releases can generally be rolled back in one of two ways. First by updating the release pointer to a previous length using the `--checkout` flag. For example:
+
+- Release "A" for channel `production` was at length `500`
+- Release "B" for channel `production` was at length `505`
+
+The release can be rolled back to "A" (aka length `500`) via the following command:
+
+```console
+pear release --checkout 500 production
+```
+
+This method doesn't add any file changes so will not show update diffs from the previous release version.
+
+The second approach is dumping the files from the previous version and staging and rereleasing the new version. This appends file changes so is heavier than just changing the release pointer, but shows update diffs and fits the [dump-stage-release strategy](../../guide/releasing-a-pear-app.md) approach since updates to the `production` channel are applied by dumping from another channel or link.
+
 ## `pear info [link|channel]`
 
 Read project information.