[RFC] Consider creating provider-gcp-beta

[hasheddan]

What problem are you facing?

As detailed in https://github.com/crossplane/provider-gcp/pull/308, having resources rely on v1beta1 GCP APIs precludes them from every reaching post-v1alphaX status because we cannot guarantee their stability. When fields are dropped or changed in the GCP API we are forced to either drop or change them in Crossplane because pinning the GCP API to a specific version blocks implementation of newer resources and features. However, we need to support v1beta1 GCP APIs in some capacity because users rely on some of the features.

How could Crossplane help solve your problem?

At the Crossplane Community Meeting on March 1st, 2020 there were a number of ideas discussed to solve this problem. The three primary variations are detailed below with pros and cons of each:

1. Add beta.<group>.gcp.crossplane.io resources for each v1beta1 GCP API group and keep all resources in the beta group as v1alphaX Crossplane APIs.
   • Pros: one install gives you all resource types
   • Cons: one install brings a ton of resource types with very similar APIs that could get mixed up, more resources affected by SDK version bumps
2. Create a new provider-gcp-beta that has resources for all of the v1beta1 GCP API groups that match the GVK of the provider-gcp v1 API resources.
   • Pros: You could theoretically use the same manifests between the two providers if you installed the opposite of the one you were using (obviously this is dependent on how much the v1beta1 and v1 APIs differ + if the Crossplane version was the same in the GVK, which it likely wouldn't be because all resources in provider-gcp-beta should remain v1alphaX)
   • Cons: Cannot install both providers at the same time, maintenance of two separate providers
3. Create a new provider-gcp-beta that has resources for all of the v1beta1 GCP API groups that have different GVK (i.e. <group>.gcp-beta.crossplane.io) than the provider-gcp v1 API resources.
   • Pros: You can install both providers at the same time, or only one if you only need it, each provider can updates its SDK versions at the desired frequency it chooses
   • Cons: maintenance of two separate providers

As could likely be gleaned from the Pros and Cons lists above, option three (3) was agreed upon as the best solution. However, this issue is meant to serve as an RFC for contributors and users to provide feedback on.