AsyncAPI V3 - Work Items

[VisualBean]

All work should be done against the vnext branch.

Preliminary info

The idea is that all of the models are updated to represent V3, but that it should still be fully serializable as V2.
In addition to this, V2 specifications should be deserialized to V3

https://www.asyncapi.com/docs/reference/specification/v3.0.0
https://github.com/asyncapi/spec-json-schemas/tree/master/definitions/3.0.0

Writing

• Add AsyncApi3_0 to AsyncApiVersion
• Go through each model one by one, and update the properties to match V3.
  • Update each SerializeV2 method, to output V2 from the V3 models - Some of these will require some bigger context, as some things have moved around quite a bit. Its important that V3 can be serialized as V2.
• Update IAsyncApiSerializable to include a void SerializeV3(IAsyncApiWriter writer);
• Update Serialize<T>(this T element, IAsyncApiWriter writer, AsyncApiVersion specificationVersion) in AsyncApiSerializableExtensions to include the new version in the switch case
• refactor needed tests, and write new ones that ensure we can write both V2 and V3.

Reading

• Update each deserializer in the V2 folder, to read into the V3 model. (Remember we are reading V2 into V3, so no need to change the left side of all of the field maps, only the right side).
• Create a new folder for V3.
• Copy each deserializer from V2 to V3 and amend the left side as needed (renaming them and ensuring proper deserialization from V3 to the V3 model.)
• Create an AsyncApiV3VersionService copying and amended from the V2 one.
• Update the Parse and ParseFragment methods in ParsingContext to include the new version service.
• refactor needed tests, and write new ones that ensure we can read both V2 and V3.

Other

• write new tests for new validation rules
• update documentation

[VisualBean]

Types done (Reading & Writing

• AsyncAPI Object
• Info Object
• Contact Object
• License Object
• Server Object
• Server Variable Object
• Channel Object
• CorrelationId Object
• Operation Object
• Operation Trait Object
• Operation Reply Object
• Operation Reply Address Object
• Parameter Object
• Server Bindings Object
• Channel Bindings Object
• Operation Bindings Object
• Message Bindings Object
• Message Object
• Message Trait Object
• Message Example Object
• Tag Object
• External Documentation Object
• Components Object
• Multi Format Schema Object
• Schema Object
• Security Scheme Object
• OAuth Flow Object

[yohanfraga]

Hello everyone,

I wanted to let you know that I've completed the following objects as part of the migration work:

Channel Object
Channel Bindings Object
Parameter Object
Message Object
Message Bindings Object
Message Trait Object
Message Example Object
External Documentation Object

Thanks!

[VisualBean]

Hello everyone,

I wanted to let you know that I've completed the following objects as part of the migration work:

Channel Object Channel Bindings Object Parameter Object Message Object Message Bindings Object Message Trait Object Message Example Object External Documentation Object

Thanks!

@yohanfraga Lets catch up so I can see what you've done!

[VisualBean]

Ive finished up most of it. Only missing Message and Components - which @yohanfraga are doing.
Note that V3 has a bunch of breaking changes - which means that the upgrade logic contains some magic inferences.
Like forcing V2 messages into components when upgrading operations -> this means forcing messages into components and referencing them - self generating a key for them.

For the interested, you can follow along here
ByteBardOrg/AsyncAPI.NET#1

[VisualBean]

Working through tests, ambiguities and bugs in the upgrade logic.

[VisualBean]

As I cannot keep the same level of support in the LEGO repository (mainly due to lack of permissions).
Iv'e decided to do a complete fork of the library over to https://github.com/ByteBardOrg/AsyncAPI.NET

Ive pushed the old vnext branch with 2.6 into the first version of ByteBard.AsyncAPI.net
and the preview version for v3 into the beta release

ByteBard.AsyncAPI.NET

ByteBard.AsyncAPI.Readers

ByteBard.AsyncAPI.Bindings

The only difference is that root level namespace being ByteBard instead of LEGO so it should be a relatively pain free migration for everyone involved.