[Feature]: Support OpenAPI 3.0.x

[ayhanap]

Tell us about your feature request

It would be nice to have the spec file published as an OpenAPI 3.0.3 file as well.

What problem are you looking to solve?

The tooling around OpenAPI spec 3.1 is quite low. Most generators have problems generating 3.1 spec files. I spent quite a while now yet to generate the a client for this spec in java.

Additional context

No response

How important is this suggestion to you?

Nice to have

[cverhelst]

For dotnet/.Net this is also blocking api-client generation since OpenAPI.DotNet still has an open ticket to add support for v3.1 and it seems like the thread mentions a source for .Net 9 not even supporting OpenAPI spec v3.1 yet.

[Haarolean]

I double this, an issue about supporting 3.1 spec in openapi-generator has been open for three years now (link), and I doubt we'll see it implemented any time soon.

[heymcgovern]

Hey folks 👋 Thanks for your patience here. We took a good look at porting our spec back to OpenAPI 3.0 but it's not feasible right now. We rely pretty heavily on features from OpenAPI 3.1, and rolling back to 3.0 would mean a substantial overhaul and ongoing maintenance that we can't commit to.

We're keeping an eye on demand for SDKs, so I've made a note that folks here are interested in .NET and Java 👀

I'm going to close this issue as "unplanned," but feel free to pop by with any extra context or thoughts.

[Haarolean]

Amazing, so having OpenAPI 3.0 spec is a maintenance you can't commit to, at the same time we can't have a proper SDK for java/.net. That's why you'd better shift the responsibility of dealing with your API (which is 30,000 lines long in OpenAPI spec!) on your customers/merchants who have to re-implement the same piece over and over for each of them.

I don't see any benefits of choosing paddle over stripe (or recently acquired lemon squeezy by them, which is a merchant of record) with these questionable business decisions in consideration.

[cverhelst]

Hey folks 👋 Thanks for your patience here. We took a good look at porting our spec back to OpenAPI 3.0 but it's not feasible right now. We rely pretty heavily on features from OpenAPI 3.1, and rolling back to 3.0 would mean a substantial overhaul and ongoing maintenance that we can't commit to.

We're keeping an eye on demand for SDKs, so I've made a note that folks here are interested in .NET and Java 👀

I'm going to close this issue as "unplanned," but feel free to pop by with any extra context or thoughts.

I appreciate the extra overhead this may cause for the team. Any option of support only a subset of the api that does not involve any of the v3.1 features?

In absence of v3.0 support, is there any alternative that may help us support the API without custom coding it ourselves in dotnet?

Right now, I've resorted to mapping the json response examples from the docs using https://quicktype.io/csharp with very loose settings (all props are optional etc) and manually fixing some of the missing values.

[ayhanap]

Here is a file that I downgraded to v3.0 manually at 29 May. I wrote down the steps which you may repeat yourself if needed (2nd file in gist).

https://gist.github.com/ayhanap/1dd580d4d88527921b46e50f9c328c27