feat(AIP-123): require singular and plural

[toumorokoshi]

Requiring singular and plural annotations on resources can enable new use cases in code generation and documentation, and prevents incorrect inferences about these values from the resource type.

See googleapis/api-linter#722 for additional discussion around the usage of singular and plural.

[bgrant0607]

Seems reasonable, but does it entirely address 1089? What about validating name/parent?

[toumorokoshi]

Seems reasonable, but does it entirely address 1089? What about validating name/parent?

Sorry, it doesn't fix #1089 at all. I must have gotten mixed up when I was batching these changes up.

Removed that tag.

[bgrant0607]

This is similar to specification of singular and plural in K8s CRDs:
https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#create-a-customresourcedefinition

There are a bunch of cases where guessing one from the other is not trivial. Plurals were a bad idea, but we are stuck with them.

So LGTM.

[bgrant0607]

On Tue, May 9, 2023 at 9:39 AM Brian Grant ***@***.***> wrote: ***@***.**** approved this pull request. This is similar to specification of singular and plural in K8s CRDs:

Link was supposed to be: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#create-a-customresourcedefinition

…

There are a bunch of cases where guessing one from the other is not trivial. Plurals were a bad idea, but we are stuck with them. So LGTM. — Reply to this email directly, view it on GitHub <#1091 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB26FUIIFSSFONTFXD7U6JTXFJXMFANCNFSM6AAAAAAXYK7JFQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[toumorokoshi]

This is similar to specification of singular and plural in K8s CRDs: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#create-a-customresourcedefinition

There are a bunch of cases where guessing one from the other is not trivial. Plurals were a bad idea, but we are stuck with them.

So LGTM.

Thanks!

one note that conflicts with the KRM CRD guidance is that the singular and plural must be camelcase camelCase. This allows lossless translation of the singular / plural from camelCase to snake_case, dash-case, etc.

KRM says all lowercase, so you don't know when one word ends and another begins.

I actually think KRM should update in kind but I doubt it's a change that's do-able now.

[noahdietz]

the singular and plural must be camelcase.

When your comment doesn't follow the guidance :P s/camelcase/camelCase/