-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
OpenAPI: Separate ListOperation from ReadOperation #21723
Merged
Merged
Changes from 1 commit
Commits
Show all changes
10 commits
Select commit
Hold shift + click to select a range
e6718ff
OpenAPI: Separate ListOperation from ReadOperation
maxb 408de42
Set further DisplayAttrs in auth/github plugin
maxb 1185ef8
Apply requested changes to operation IDs
maxb 898bc36
Adjust logic to prevent any possibility of generating OpenAPI paths w…
maxb aeb4289
changelog
maxb 6bfe9e8
Merge branch 'main' into full-openapi-list-separation
maxb d037477
Fix TestSudoPaths to pass again... which snowballed a bit...
maxb 01cb30b
Fix other tests
maxb 1d4680a
More test fixing
maxb 51f7a03
Undo scope creep - back away from fixing sudo paths not shown as such…
maxb File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Note to reviewer:
DisplayNavigation
removed as wholly unused.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.
🤔 If I understand correctly, removing a public field of a public struct in our SDK is a breaking change in terms of binary compatibility and so breaks SemVer and therefore Go mod's rules.
I don't know the ecosystem well enough to estimate whether this would actually impact any real downstream code, but for example it could cause downstream code to fail to build if they are referring to this field. In general in other HashiCorp public modules we are relatively conservative about this kind of thing.
I'd be happy to be advised by any one who knows the code better whether there is some exceptional circumstance that makes it seem OK in this case, but my instinct would be to not remove this and avoid the issue entirely. I certainly don't think it's worth making a v2 of the whole sdk module to change this but that would be the "correct" way to do it I think.
Am I missing some reason this is fine?
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.
You are correct it is a compatibility break. (Though given that Go doesn't generally ship libraries as binaries, but as source code, it's more a source compatibility issue than a binary one.)
However, the version of the SDK is v0.x.x, and the Go versioning rules explicitly declare that version zero is way of declaring a module has yet to implement any compatibility guarantees as it is still in development. Therefore, by keeping the SDK version at v0.x.x, the implicit message is that rights are reserved to break compatibility as desired.
(In contrast, the API package is v1.x.x implying compatibility will be maintained.)
I'd need to do a quick bit of research to confirm, but I think the SDK's lack of compatibility guarantees has been exercised in the past - e.g. in recent changes to decouple the Vault version number from the SDK.
Practically speaking, the field is located in a type which is only used to perform JSON serialization of OpenAPI specifications, internally to the SDK. It is very likely that it has zero uses in the wider ecosystem.
Therefore whilst it is a compatibility break, there are both technical and pragmatic reasons to believe that it is fine to do so.
However it is only a bit of cleanup in passing, and I would be happy to remove that change from this PR, if you prefer it that way.
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.
I'll defer to @averche on whether it's preferable to leave it alone but I'd not noticed the v0.* tag which I think tips the whole thing towards being defensible in my mind 😄. Thanks for helping me understand Max!
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.
I agree with @maxb on the rationale behind breaking the backwards compatibility and I think it's OK to remove this 👍
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.
Just to indulge my curiosity about the compatibility issue, I ran previous versions of the SDK through an API diff tool:
Incompatible changes between v0.2.0 and v0.2.1
Incompatible changes between v0.2.1 and v0.3.0
Incompatible changes between v0.3.0 and v0.4.0
Incompatible changes between v0.4.0 and v0.4.1
Incompatible changes between v0.4.1 and v0.5.0
Incompatible changes between v0.5.0 and v0.5.1
Incompatible changes between v0.5.1 and v0.5.2
Incompatible changes between v0.5.2 and v0.5.3
Incompatible changes between v0.5.3 and v0.6.0
Incompatible changes between v0.6.0 and v0.6.1
Incompatible changes between v0.6.1 and v0.6.2
Incompatible changes between v0.6.2 and v0.7.0
Incompatible changes between v0.7.0 and v0.8.0
Incompatible changes between v0.8.0 and v0.8.1
Incompatible changes between v0.8.1 and v0.9.0
Incompatible changes between v0.9.0 and v0.9.1
Incompatible changes between v0.9.1 and HEAD
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.
It turns out the supposedly compatible API has fudged things a bit in the past, too:
Incompatible changes between v1.0.4 and v1.1.0
Incompatible changes between v1.5.0 and v1.6.0
Incompatible changes between v1.7.2 and v1.8.0
Incompatible changes between v1.8.0 and v1.8.1
Incompatible changes between v1.8.2 and v1.8.3
Incompatible changes between v1.9.0 and v1.9.1