Address code review

Author: sjberman

docs/developer/crd-versioning.md

@@ -13,6 +13,7 @@ When changing an API in a CRD, it's important to understand the impact of those
 **No change in version required**
 
 - Adding new optional fields.
+- Documentation updates.
 
 **Compatible changes, requires a version change**
 
@@ -21,6 +22,8 @@ When changing an API in a CRD, it's important to understand the impact of those
   - The new API should not be marked as the preferred or `stored` version until old API is removed.
   - To reduce complexity, we should only support a maximum of 2 API versions at the same time.
 
+For more in depth information on compatible changes, see the Kubernetes [API changes doc](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md#on-compatibility).
+
 **Breaking changes, requires a version change**
 
 The following API changes are incompatible with previous API versions, and therefore not only require a version bump, but cannot use a conversion webhook. These types of changes should be avoided if at all possible due to the disruption for users. A user will need to update their configurations when upgrading NGF. These types of changes need clear messaging in release notes and docs.
@@ -31,7 +34,7 @@ We'll allow a bit more flexibility for this case when dealing with alpha APIs.
 - Removing fields. If possible, we should try to deprecate fields for 3 releases to slowly phase them out before removing.
 - Changing validation and allowed values of a field.
 
-For more in depth information on how to handle API changes, see the Kubernetes [API changes doc](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md).
+For more in depth information on how to handle API changes, see the Kubernetes [API changes doc](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md#backward-compatibility-gotchas).
 
 
 NGF version should not need to change when CRD versions change. CRDs are not embedded into NGF; they have their own versions. NGF releases are directly tied to the CRD version they support and users are required to upgrade CRD versions when upgrading NGF. This ensures that the CRD version is supported by NGF. However, the user may need to fix their CRDs if they aren't compatible.
@@ -43,4 +46,9 @@ Having an alpha API allows us more flexibility in making breaking API changes as
 
 When we've determined that an API is stable and should no longer have breaking changes or refactors, we can promote it to `v1`. Once promoted, this API **should not** be subject to changes that require a version bump. Only when absolutely necessary should we consider changes that would lead to a `v2alpha1` or `v2` version.
 
+We are skipping the usual alpha -> beta -> v1 graduation for a couple of reasons.
+
+1. It matches the pattern of Gateway API graduation.
+2. Our APIs are likely going to be simple enough that we don't need to go through 3 stages of graduation. There is overhead in this that is probably not necessary for our project.
+
 Since we are still early in the API development process for NGF, a specific timeframe for this is not yet determined. We need to get user feedback to determine if the APIs are being utilized and if any issues arise.