drop asyncapi json schemas prior 2.0 and release 4.0

[derberg]

we still expose AsyncAPI 1.0, 1.1 and 1.2 but we do not really support it anymore.

we should remove it and release new major

these old schemas use draft 4 as base. The new ones use draft 7. So in parser we are forced to point to draft 4 as meta schema for ajv. So we do something in the parser that do not make much sense, as parser do not support asyncapi prior 2.0

thoughts?

cc approvers @fmvilas @dalelane

[magicmatatjahu]

The plus is that then the final bundle will be reduced, e.g. for parser, because the all schemas alone take up about 300kb.

[smoya]

+1 this but I would keep the schemas and rather remove them from the list of schemas the Parser uses. See #248.

Why should we still serve those files? Simple: users can still want to use those schemas on their own, without the support of the tooling or the community.

[derberg]

@smoya just to make sure, you are ok to remove it from the package, but want to keep it in the repo?

[smoya]

@smoya just to make sure, you are ok to remove it from the package, but want to keep it in the repo?

Not exactly. I meant to still include those in the package but remove it from the exported list. Still the package won't be reduced in terms of size, but the bundled applications won't contain those ergo will be lighter and still give support for those that need it. We could export unsupportedVersions with those or just apply what @magicmatatjahu is doing in #248 (does the other way around by exporting supportedVersions).

Another solution could be to publish two different packages, @asyncapi/types and @asyncapi/deprecated-types 🤷

[derberg]

Can you explain why should package provide something that is not supported, what is the use case? I think this is what versioning is for. If you want to support 1.0.0 of spec then use the old package version, or just fetch files from github. Keeping unsupported features is not encouraging folks to upgrade, right?

[smoya]

Can you explain why should package provide something that is not supported, what is the use case? I think this is what versioning is for. If you want to support 1.0.0 of spec then use the old package version, or just fetch files from github. Keeping unsupported features is not encouraging folks to upgrade, right?

I think you are right and we should remove support for all those versions in the package as well. If people wants to keep up with latest tooling versions they would need to upgrade their AsyncAPI documents to at least 2.0.0, which is totally considerable.

I would then only leave the schema files in the repository so they are accessible and downloadable still.

[magicmatatjahu]

PR for that :) #248

cc @derberg @smoya

[asyncapi-bot]

🎉 This issue has been resolved in version 4.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀