-
Notifications
You must be signed in to change notification settings - Fork 9.1k
Draft release notes for 3.2.0 and 3.1.2 #4600
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
base: main
Are you sure you want to change the base?
Conversation
@lornajane So far looks good to me. |
Co-authored-by: Vincent Biret <vincentbiret@hotmail.com>
should add more detailed info on new keywords in MediaType object. |
Co-authored-by: Ralf Handl <ralf.handl@sap.com>
@jeremyfiel can you say something about what's missing? (I obviously don't know or it wouldn't be missing ...) I did just update with some of the changes from the last couple of weeks, but I don't think there is anything here that would match what you're asking for. |
I'd like to propose a slightly different ordering to improve the storytelling around this release:
This would give us a flow more like the following: 3.2 UpdatesTagsData Modeling and RepresentationOAS v3.2 makes significant progress towards more consistent, modular, and extensible media type and parameter support, while also expanding the set of media types supported in response to both emerging and legacy use cases. In addition, we have removed ambiguity regarding how to present examples in a variety of complex scenarios. Media Type RegistrySequential and Streaming Media TypesParameters and HeadersMultipart Media TypesXMLCode GenerationExample ObjectAdditional Major AdditionsNote: This subsection ordering within this section makes sense to me, but I do not feel strongly about it. MethodsDocument Identification and Reference ResolutionSecuritySmaller ImprovementsServers, Paths, and Runtime ExpressionsResponsesUpdated to New Versions of Other Standardsetc. |
There's about 50% more spec change since I wrote this draft, re ordering definitely in our future! Thanks for the outline , I'll be trying to catch up this week |
Co-authored-by: Henry Andrews <andrews_henry@yahoo.com>
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.
Nice!
Co-authored-by: Henry Andrews <andrews_henry@yahoo.com>
Started adding the suggested structure (in 3 parts: digestible high level features, the masterpieces of data modeling, and then everything else), but I note that we don't have all the sections you mentioned @handrews , in particular:
|
|
||
- New `summary` field to allow short descriptions, used when displaying lists of tags. If you use the `x-displayName` extension, you can now use `summary` instead. | ||
- `parent` field to point to the tag that this tag is nested under. If you use `x-tagGroups`, adjust to use a tags hierarchy. | ||
- `kind` to allow multiple categories of tag. The `kind` field is free-form text, however there are some expected/conventional values such as `nav` (in line with the most common current usage as grouping for documentation output). |
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.
- `kind` to allow multiple categories of tag. The `kind` field is free-form text, however there are some expected/conventional values such as `nav` (in line with the most common current usage as grouping for documentation output). | |
- `kind` to allow multiple categories of tags. The `kind` field is free-form text, however there are some expected/conventional values such as `nav` (in line with the most common current usage as grouping for documentation output). |
#### Support additional HTTP methods | ||
|
||
- Support the new `query` method alongside the existing `get`/`post`/`put`/`delete`/`options`/`head`/`patch`/`trace`. | ||
- Under an `additionalOperations` entry in a Path, use any other methods not listed as keys using the correct capitalization. e.g. do NOT add HEAD under this, use the existing sibling `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.
- Under an `additionalOperations` entry in a Path, use any other methods not listed as keys using the correct capitalization. e.g. do NOT add HEAD under this, use the existing sibling `head`. | |
- Under an `additionalOperations` entry in a Path, use any other methods not listed as keys using the correct capitalization, e.g. `COPY`. Do NOT add `HEAD` under this, use the existing sibling `head`. |
- Explanation and examples for many use cases including handling `null`, handling arrays, replacing the name, and handling ordered elements. | ||
- Clarify that the root schema of an XML object should use the component name. | ||
|
||
#### Show examples in both structure and serialized forms |
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.
#### Show examples in both structure and serialized forms | |
#### Show examples in both structured and serialized forms |
- How to more clearly indicate that responses will not have a body. | ||
- Explanation and examples of headers including `Link` and `Set-Cookie`. | ||
- No change but extensive additional notes on parsing and serializing JSON and non-JSON data formats. | ||
Particularly if you are buildling OpenAPI tooling, this section gives much better guidance on some of those tricky edge cases. |
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.
Particularly if you are buildling OpenAPI tooling, this section gives much better guidance on some of those tricky edge cases. | |
Particularly if you are building OpenAPI tooling, this section gives much better guidance on some of those tricky edge cases. |
- Other URLs, such as to external documentation or a license, are resolved against the base URI. | ||
- Relative links inside `description` fields are resolved relative to their rendered context, such as your published API documentation page. | ||
- API endpoints are resolved against the URL in the Server Object, which itself might be relative and resolved against the base URI. |
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.
- Other URLs, such as to external documentation or a license, are resolved against the base URI. | |
- Relative links inside `description` fields are resolved relative to their rendered context, such as your published API documentation page. | |
- API endpoints are resolved against the URL in the Server Object, which itself might be relative and resolved against the base URI. | |
- Other URLs, such as to external documentation or a license, are resolved against the base URI. | |
- Relative links inside `description` fields are resolved relative to their rendered context, such as your published API documentation page. | |
- API endpoints are resolved against the URL in the Server Object, which itself might be relative and resolved against the base URI. |
To satisfy our markdown-lint rules
Opening this as a pull request purely as a good way to collaborate - DO NOT MERGE.
The content will be added to the github release.