OpenAPi 3.1

[rugk]

OpenAPI 3.1 has been released, so to stay future-compatible, you'd need to update your project here too. 🙂

[philsturgeon]

Here are a few articles showing off the differences between OpenAPI v3.0 and v3.1.

• https://www.openapis.org/blog/2021/02/16/migrating-from-openapi-3-0-to-3-1-0
• https://www.apimatic.io/blog/2021/09/migrating-to-and-from-openapi-3-1/
• https://nordicapis.com/whats-new-in-openapi-3-1-0/

Here are some example files which can make for handy pass/fail test cases:

https://github.com/Mermade/openapi3-examples/tree/master/3.1

If you're looking for the JSON Schema that defines a valid OpenAPI document, that'll be right over here:

https://github.com/OAI/OpenAPI-Specification/tree/main/schemas/v3.1

No rush, but when you're starting work on it, please update this issue so I can update openapi.tools to reflect that, and folks will have a way to subscribe for updates.

If there are no plans to make it happen, please archive this repo so there's no confusion about whats going on. I know how tough it can be to keep dedicating time to an OSS project thats not being used much anymore, so help point folks to another tool which will do what they want (loads of them on https://openapi.tools/).

[waldyrious]

If there are no plans to make it happen, please archive this repo

That's a rather drastic solution. A better approach, IMO, would be to add a disclaimer in the README and tagline, and maybe a status badge. That would allow people who come across this tool, and prefer its approach to others (a low-barrier OpenAPI renderer based entirely on github-pages, with no explicit build step), to contribute to it and add missing features. That was what I did back when I had the need, anyway. (And to be clear, I wouldn't have forked and started my own project, as I didn't have the bandwidth for that commitment.)

Archiving the project would lock it from contributions and even issues/discussions, e.g. to ask the project creator whether PRs would be accepted, offers to maintain the tool, etc.

[philsturgeon]

@waldyrious to be fair there hasn't been a commit/merge since June 2021, you said that in April 2022, it's now October 2022. Archiving this and helping redirect people to modern alternatives would be a good choice IMO.

[waldyrious]

Why do you consider that a README notice and status badge (stating that there's no active development, that contributions are accepted but may be slow to be reviewed, and that additional maintainers may be considered) would be a worse course of action than archiving the repo? The latter IMO is worse, because it unilaterally forbids others from even opening issues (e.g. to offer to maintain the tool).

[philsturgeon]

I support either, I was just saying the argument was moot.

…

On Wed, Oct 19, 2022 at 18:12, Waldir Pimenta ***@***.***> wrote: Why do you consider that a README notice and status badge (stating that there's no active development, that contributions are accepted but may be slow to be reviewed, and that additional maintainers may be considered) would be a worse course of action than archiving the repo? The latter IMO is worse, because it unilaterally forbids others from even opening issues (e.g. to offer to maintain the tool). — Reply to this email directly, [view it on GitHub](#7 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAAQONMMVBDMKNDIEUBXI3DWEATW3ANCNFSM4YMD723Q). You are receiving this because you commented.Message ID: ***@***.***>

[waldyrious]

Cool, thanks for clarifying. I would do the updates myself if I had write access to the repository, but unfortunately as it stands we'd need @robertlove to accept the changes anyway. So the only thing we can do for now is wait until he's able to comment on this issue.