feat: allow re-usability of Server Variable Objects

[char0n]

Refs #775

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[fmvilas]

Answering your comment in the #775 issue:

I've issued a #776 that remedies the situation and would probably suggest to go for 2.4.1 as soon as possible.

Yeah, I think it's a pretty good use case for a patch version.

[fmvilas]

Looks good to me. Let's wait for the other code owners to review it.

Would also love @smoya and @danielkocot to have a look since they've been involved in the last release.

[fmvilas]

/dnm

[magicmatatjahu]

Do we really have to do 2.4.1? In my opinion, it's more of an oversight and that doesn't change the structure of the specification at all. When OpenAPI 3.1.0 came out, people were still making small improvements to the spec without releasing 3.1.1.

[char0n]

Do we really have to do 2.4.1? In my opinion

No, it's not really necessary, I've just suggested it given the quick cadence of release process for the spec.

it's more of an oversight and that doesn't change the structure of the specification at all.

IMHO it does change the capabilities of the specification; strictly speaking it extends the capabilities, so feat would be more appropriate, but given the context and the fact that this is oversight I went with fix.

When OpenAPI 3.1.0 came out, people were still making small improvements to the spec without releasing 3.1.1.

Not sure this is correct observation (but I might be mistaken). OAS is considered immutable and the last commit to the 3.1.0 version is actually the release commit. No commits after that.

Commit history for the 3.1.0 spec: https://github.com/OAI/OpenAPI-Specification/commits/main/versions/3.1.0.md

[danielkocot]

For me it looks also good. Thanks @char0n for extending the idea of reusability.

[smoya]

LGTM!

Even though I don't like the idea of releasing a patch, I agree @char0n it is appropriate in this case. The spec is defined in this repository, and not in the json schema definitions (those are supporting the spec, not defining them IMHO), meaning this should be released as what it is, a fix.
I would not release it as a minor since, even though this introduces a new feature technically speaking, the intention on 2.4.0 was to support this and we missed this change, so It can be considered a bug (ergo this fix).

[char0n]

The spec is defined in this repository, and not in the json schema definitions (those are supporting the spec, not defining them IMHO)

This has come up multiple times already during different conversations. What is actually the source of truth? I've created an issue to track this unclarity and the PR that tries to remedy it. IMHO the source of truth is always the makrdown specification.

[derberg]

releasing a patch doesn't hurt 😄
we just merge and it magically happens 😄

all good on JSON Schema side?

[smoya]

releasing a patch doesn't hurt 😄 we just merge and it magically happens 😄

all good on JSON Schema side?

All good as $ref is allowed as additional property: https://github.com/asyncapi/spec-json-schemas/blob/master/schemas/2.4.0.json#L209-L213

[smoya]

@dalelane @fmvilas your review is needed here. Thanks!

[char0n]

Given we've discontinued effort with 2.4.1 release and are going directly for 2.5.0, this PR needs to be send against next-spec and the title needs to changeto feat: allow re-usability of Server Variable Objects

[derberg]

@char0n yup, I think you should be able to change the base branch

[char0n]

Right, I'll do it right after #831 is merged. I guess it would require re-review of all code owners.

[char0n]

Base branch changed for next-spec.

[char0n]

/ready-to-merge

[char0n]

Changed title from fix: allow re-usability of Server Variable Objects to feat: allow re-usability of Server Variable Objects. Can I ask somebody to to remove do-not-merge label or merge this PR? Thanks!

[derberg]

/rtm

[asyncapi-bot]

🎉 This PR is included in version 2.5.0-next-spec.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀