Build & Release versioning documentation update (#91)

## Description
Documentation update on how to manage build & release versions & tags.

## Type of change
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [X] This change requires a documentation update

## How Has This Been Tested?
NA

## Checklist:
NA

docs/build/README.md

@@ -1,17 +1,21 @@
-# Build System
+# Building & Versioning
 
-The build system we're using, mage, has been introduced with four targets; testing it involves invoking them and looking at their output.
+## Release Tag Versioning
 
-## Versioning
+We follow Go's [Module Version Numbering](https://go.dev/doc/modules/version-numbers) for software releases along with typical [Software release life cycles](https://en.wikipedia.org/wiki/Software_release_life_cycle).
 
-All the targets that produce a binary should inject version information on it, which can be inspected by running the executable with the `-version` flag.
+For example, `v0.0.1-alpha.pre.1` is the tag used for the first milestone merge and `v0.0.1-alpha.1` can be used for the first official alpha release.
 
-If built outside a repository, or without the `git` executable in the path, it should report the version `UNKNOWN`.
+## [WIP] Build Versioning
 
-If built in a repository where uncommitted changes are present, the version should report a version with `+dirty`
+Automatic development / test / production builds are still a work in progress, but we plan to incorporate the following when we reach that point:
 
-Version reported for a proper git repository with the `git` executable present in the path should be `0.0.0-branch_name/commit_hash`, where the version number is fixed but the branch name reflects the current branch and the commit hash likewise the current commit's hash.
+- `+dirty` for uncommited changes
+- `-version` flag that can be injected or defaults to `UNKNOWN`
+- `branch_name` and a shortened `commit_hash` shold be included
 
-## Magefile build system
+For example, `X.Y.Z[-<pre_release_tag][+branch_name][+short_hash][+dirty]` is the name of a potential build we will release in the future.
+
+## [TODO] Magefile build system
 
 Once the V1 implementation reaches the stage of testable binaries, we are looking to use [Mage](https://magefile.org/) which is being tracked in [pocket/issues/43](https://github.com/pokt-network/pocket/issues/43) that'll inject a version with the `-version` flag.