-
Notifications
You must be signed in to change notification settings - Fork 464
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(AIP-149): differentiate field presence and behavior #1143
fix(AIP-149): differentiate field presence and behavior #1143
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple of comments, but basically fine. I strongly suspect we'll want to elaborate on this over time, but that's okay.
address feedback Co-authored-by: Jon Skeet <skeet@pobox.com> link AIP-203
4b98c5b
to
ff4ce17
Compare
Needed to force push to get around a commit co-author addition that tripped the CLA checker. No content changes. |
|
||
**Important:** Tracking field presence is *not* the same as documenting API | ||
field behavior as defined in [AIP-203][]. For example, a field labeled with | ||
`optional` for presence tracking **may** also be annotated as |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should there be a cross-reference to http://cloud/apis/design/design_patterns.md#optional_primitive_fields ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bah! Shouldn't that link to this AIP? Anyways, discussion of primitives, etc. is part of the guidance above, I don't think we need to discuss it further in this note. Is that fair?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I'd rather move more to the AIPs. it's more actively maintained.
The bifurcation cloud APIs and AIPs is a known issue though - when we have more breathing room we should probably tackle that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks!
An internal discussion determined that
google.api.field_behavior
andproto3_optional
are separate features and can be used simultaneously. See Rationale in this PR for more detailed reasoning.Updates: googleapis/api-linter#1169