Mark alpha/beta classes with @deprecated when a stable version exists

[bshaffer]

Deprecate alpha / beta clients (e.g. v1beta1 Firestore) by adding @deprecated to the GAPIC client classes (and potentially all classes) with the logic that "if Vn exists, then Vn(\w+) should be marked as deprecated". e.g.:

• Asset\V1 and Asset\V1beta1
• AutoMl\V1 and AutoMl\V1beta1
• BillingBudgets\V1 and BillingBudgets\V1beta1
• DataprocMetastore\V1, DataprocMetastore\V1alpha, and DataprocMetastore\V1beta
• Firestore\V1 and Firestore\V1beta1
• Language\V1 and Language\V1beta2
• ManagedIdentities\V1 and ManagedIdentities\V1beta1
• Memcache\V1 and Memcache\V1beta2
• OsLogin\V1 and OsLogin\V1beta
• Redis\V1 and Redis\V1beta1
• Scheduler\V1 and Scheduler\V1beta1
• SecretManager\V1 and SecretManager\V1beta1
• SecurityPrivateCa\V1 and SecurityPrivateCa\V1beta1
• SecurityCenter\V1 and SecurityCenter\V1p1beta1
• ServiceDirectory\V1 and ServiceDirectory\V1beta1
• Speech\V1 and Speech\V1p1beta1
• Talent\V4 abd Talent\V4beta1
• Tasks\V2, Tasks\V2beta2 and Tasks\V2beta3
• WebRisk\V1 and WebRisk\V1beta1
• VideoIntelligence\V1 and VideoIntelligence\V1beta2
• VideoTranscoder\V1 and VideoTranscoder\V1beta1

[noahdietz]

I don't think this is entirely true (that alpha/beta should be deprecated when "stable" exists). Services can use their alpha/beta channel API versions for testing new features before deciding to promote them to the stable version. Compute does this. Furthermore, I don't think we should be deprecating a service, whether Alpha or Beta, unless the proto is actually marked as "deprecated" and the service team has announced deprecation.

Also, each GAPIC is generated in isolation, so while generating a single beta service client there is no way to infer if there is a stable version of that same service.

This would require an extra option.

[bshaffer]

Services can use their alpha/beta channel API versions for testing new features before deciding to promote them to the stable version

Interesting, they do this even after publishing a stable version? TIL

while generating a single beta service client there is no way to infer if there is a stable version

This makes sense - essentially at time of generation, the generator does not have enough context to know that there is a stable version. Would this still be the case if we put the logic in the "post processor" step?

This would require an extra option.

I agree. And in a post-processor step we can add @deprecated to ALL classes in a version. Until then, we can simply add @deprecated to the Client classes that extend the GapicClient if we want that behavior.