[DOC] Define procedure and convention for val updates to official releases (#1188)

* Document a procedure and naming convention for validation updates to official releases

* Use a bigger number to end an example series so the '...' makes sense

* Define support for multiple chained descriptors in a build id

Author: calebofearth

docs/CaliptraReleaseChecklist.md

@@ -18,13 +18,20 @@ Caliptra RTL releases may be created for new major, minor, or patch versions, as
 
 Pre-release versions are denoted with the alphanumeric key `rc<incrementing_numeric_value>` to indicate that the version is a release candidate. Release candidates are tagged to indicate that feature and validation effort has reached a finalized state, and the final release is pending further review. An example release candidate tag is: `v2.2.0-rc3`
 
-Modifications may also be applied to the documentation of a patch release by opening pull requests to the `patch_v<MAJOR>.<MINOR>` branch. When a release receives updates to the documentation (with no other modifications) this is considered a new "build" from a versioning perspective. Semantic versioning specifies that build metadata can be included in a release version by appending build data to the version. The format for appending build information is: `<MAJOR>.<MINOR>.<PATCH>+<build_identifier>`.
-In caliptra-rtl releases, the `build_identifier` is always an alphanumeric key that begins with a 1-indexed numeric value. The full format of the build identifier is: `<incrementing_numeric_value>.<alphanumeric_descriptor>`.
-The only supported value for `<alphanumeric_descriptor>` is the keyword `doc`.
+Modifications may also be applied to supporting collateral of a patch release (non-RTL code such as documentation, test scripts, and validation environment) by opening pull requests to the `patch_v<MAJOR>.<MINOR>` branch. When a release receives updates to the documentation or validation material (with no other modifications) this is considered a new "build" from a versioning perspective. Semantic versioning specifies that build metadata can be included in a release version by appending build data to the version. The format for appending build information is: `<MAJOR>.<MINOR>.<PATCH>+<build_identifier>`.
+In caliptra-rtl releases, the `build_identifier` is always an alphanumeric key that begins with a 1-indexed numeric value. The full format of the build identifier is: `<incrementing_numeric_value>.<alphanumeric_descriptor>[.<alphanumeric_descriptor>]`.
+The only supported values for `<alphanumeric_descriptor>` are the keywords `doc` and `val`. Multiple alphanumeric_descriptor values may be chained together using '.' as a delimiter. When chained together, alphanumeric_descriptor values will always be ordered with higher precedence descriptors shown first, in decreasing precedence. The order of precedence for supported descriptors is shown in the following table:
+| Precedence | alphanumeric_descriptor |
+| :-- | :-- |
+| Highest | `val` |
+| Lowest | `doc` |
 
-For example, a series of documentation updates to the 2.0.2 release of caliptra-rtl would be tagged as: `v2.0.2+1.doc`, `v2.0.2+2.doc`, ... , `v2.0.2+12.doc`.
 
-Documentation updates are only applied to the latest patch release. That is, documentation updates to produce `v2.0.2+3.doc` are not applied to any `v2.0.1` release. A newer patch release inherits all documentation updates from prior patch releases, and may then be subsequently targeted for additional documentation updates. Thus, there is no guarantee that documentation from a given build is applicable to a prior patch release, as patch updates may have modified the area described in the documentation.
+As a few examples:
+- A series of documentation updates to the 2.0.2 release of caliptra-rtl would be tagged as: `v2.0.2+1.doc`, `v2.0.2+2.doc`, ... , `v2.0.2+12.doc`.
+- A series of documentation and validation updates to the 2.1.1 release of caliptra-rtl might be tagged as: `v2.1.1+1.doc`, `v2.1.1+2.val`, ... `v2.1.1+16.val.doc`, `v2.1.1+17.doc`.
+
+Non-RTL updates are only applied to the latest patch release. That is, documentation updates to produce `v2.0.2+3.doc` are not applied to any `v2.0.1` release. A newer patch release inherits all documentation updates from prior patch releases, and may then be subsequently targeted for additional documentation updates. Thus, there is no guarantee that documentation from a given build is applicable to a prior patch release, as patch updates may have modified the area described in the documentation.
 
 ## Branches