Work on 2.4 release

[smoya]

Release 2.4.0 is scheduled for April 2022

Detailed info:

• https://github.com/asyncapi/spec/blob/master/RELEASE_PROCESS.md

Kick-off:

• TODO: Community SIG Meeting, 8 UTC Tuesday March 22 2022 community#294

Release branches:

• https://github.com/asyncapi/spec/tree/2022-04-release
• https://github.com/asyncapi/spec-json-schemas/tree/2022-04-release
• https://github.com/asyncapi/parser-js/tree/2022-04-release

Release notes:

• TODO draft PR - https://github.com/asyncapi/website/pull/PULLREQUEST

Progress:

• Create release branches
  • spec
  • spec-json-schemas
  • parser-js
• Update release branches with new versions
  • spec - chore: update 2022-04-release branch #736
  • spec-json-schemas- chore: update 2022-04-release branch spec-json-schemas#182
  • parser-js - chore: update 2022-04-release branch parser-js#494
• Update default branches with release branch name
  • spec - chore: add 2022-04-release branch in .releaserc #737
  • spec-json-schemas - chore: enable prereleases for 2022-04-release branch spec-json-schemas#183
  • parser-js - chore: enable prereleases for 2022-04-release branch parser-js#495
• Create draft release notes - feat(blog): add release notes for 2.4 release website#634
• Update release branches from forks
  • spec - chore: update 2022-04-release branch with master changes #741
  • spec-json-schemas
  • parser-js- chore: update 2022-04-release branch with master changes parser-js#502
• Notify community about release branches
• Check for potential release contributions
• Draft announcement blog post for new features and changes
• Write release notes for new features and changes
• Prepare pull requests to merge release branches into master
  • spec
  • spec-json-schemas
  • parser-js
• Notify tsc_members about upcoming release
• Merge release branches into master
  • spec
  • spec-json-schemas
  • parser-js
• Write release notes for the releases on Github
• Create releases on Github
  • spec
  • spec-json-schemas
  • parser-js
• Update RELEASE_PROCESS doc with any changes

Cleanup tasks for this particular version

• To include next-spec and next-major-spec branches into .releaserc or package.json files Use next branch for next minor releases #734

Potential work to be included in this version

Accepted

• Make Server Variables Object available as reusable objects under the Component object #707
  • feat: added server variable object as reusable object #717
  • feat: make server variables reuseable spec-json-schemas#174
  • feat: add methods and tests for serverVariables parser-js#476
• feat: add security at the operation level #584
  • feat: add security at the operation level #584
  • feat: security support added to operation and operationTrait  spec-json-schemas#189
  • feat: add security field at the operation level parser-js#505
• Add support for messageId #458
  • feat: add messageId property #751
  • feat: add messageId property spec-json-schemas#195
  • feat: add support for messageId parser-js#510
• Unable to reuse Server Objects defined in Components.servers field #705
  • fix(Servers): allow to use union type of Server and Reference objects #706

Pending

Discarded

• feat: add operations to the components object #749
• Proposal to introduce notion of environments #623
• Allow grouping servers #654
• Add "channelContext" property to server object #527

[smoya]

I wonder if we would want to build the changes on our JSON Schema files based on asyncapi/spec-json-schemas#128.

Such change is a breaking change for the spec-json-schemas repository (that's why it was merged into next-major). It is considered a breaking change because $id field values are completely changed now.
That means any tool that depends explicitly on those $id will break. That includes parser-js. BTW, the "fix" is short: https://github.com/asyncapi/parser-js/pull/423/files.

Would it make sense to release spec-json-schemas new major version (including the split schemas) and build the changes required for spec 2.4.0 on top of it? I would say yes. The new minor version we will release for the parser-js could point to the major spec-json-schemas release.

Is there anything else I'm missing that stop us from doing that?

cc @derberg @jonaslagoni

[smoya]

I wonder if we would want to build the changes on our JSON Schema files based on asyncapi/spec-json-schemas#128.

Such change is a breaking change for the spec-json-schemas repository (that's why it was merged into next-major). It is considered a breaking change because $id field values are completely changed now. That means any tool that depends explicitly on those $id will break. That includes parser-js. BTW, the "fix" is short: https://github.com/asyncapi/parser-js/pull/423/files.

Would it make sense to release spec-json-schemas new major version (including the split schemas) and build the changes required for spec 2.4.0 on top of it? I would say yes. The new minor version we will release for the parser-js could point to the major spec-json-schemas release.

Is there anything else I'm missing that stop us from doing that?

cc @derberg @jonaslagoni

As it seems there are no cons for building on top of the new definitions structure, we will do once asyncapi/spec-json-schemas#184 is merged.

[smoya]

I'm keeping a list in the description of the issue with the potential work to be included in this release.

[smoya]

Would it make sense to release spec-json-schemas new major version (including the split schemas) and build the changes required for spec 2.4.0 on top of it? I would say yes. The new minor version we will release for the parser-js could point to the major spec-json-schemas release.

For this version, we are gonna keep working with the current schemas structure (master branch). More info here: asyncapi/spec-json-schemas#184

[smoya]

Complementing https://asyncapi.slack.com/archives/CQVJXFNQL/p1650543345479079

The AsyncAPI spec 2.4.0 release is gonna happen between tomorrow and the day after approx.
All features have been merged and are available under prereleases.

Those are the merged features:

• feat: add security at the operation level #584.
• Make Server Variables Object available as reusable objects under the Component object #707
• Add support for messageId #458

I’m pinging code owners of the repositories affected so you can start preparing the needed updates:

• Avro Schema parser
• Bundler
• CLI
• Cupid
• Dot Net NATS template
• Generator
• Generator React SDK
• Glee
• Java Template
• JavaScript Converter
• Markdown template
• Modelina
• NodeJS WS Template
• Optimizer
• Parser Go
• React component
• Server API
• Simulator
• Studio
• TS NATS Template

@derberg @magicmatatjahu @fmvilas @jonaslagoni @dalelane @M3lkior @Souvikns @boyney123 @arjungarg07 @AGurlhosur @dan-r @KieranM1999 @lewis-relph @JEFFLUFC @KhudaDad414 @smoya @BOLT04 @NektariosFifes @mcturco

EDIT:

I think I wasn’t pretty clear with this message. Dependencies are bumped automatically by CI/CD automation once the release happens.
Only some critical projects will need to do some extra work:

• https://github.com/asyncapi/html-template
• https://github.com/asyncapi/converter-js/
• https://github.com/asyncapi/asyncapi-react/
• https://github.com/asyncapi/studio

I added the clarification in the RELEASE_PROCESS.md file so this doesn’t happen again: #770

[smoya]

Starting the release process right now cc @derberg @dalelane @fmvilas

[smoya]

AsyncAPI 2.4.0 got finally released 🚀 🎉

[smoya]

With #791 and asyncapi/community#357, I think I have finished all the work I planned to do regarding 2.4.

Anything to add? Can we close this issue instead? cc @dalelane @fmvilas @derberg

[derberg]

👏🏼 👏🏼 👏🏼 👏🏼 👏🏼 👏🏼 👏🏼 well handled + lots of improvements added 🙏🏼

[dalelane]

looks good to me 👍

[fmvilas]

Great work, @smoya! 👏 👏