From 3dc4603471b3fadb70151a66082cca52119ad3ff Mon Sep 17 00:00:00 2001 From: Dale Lane Date: Thu, 10 Feb 2022 15:19:39 +0000 Subject: [PATCH 01/14] wip --- RELEASE_PROCESS.md | 246 +++++++++++++++++++++++++++++++++++++-------- 1 file changed, 205 insertions(+), 41 deletions(-) diff --git a/RELEASE_PROCESS.md b/RELEASE_PROCESS.md index 12625861..e9504b12 100644 --- a/RELEASE_PROCESS.md +++ b/RELEASE_PROCESS.md @@ -1,14 +1,34 @@ # Release Process of the AsyncAPI Specification -This document is meant to explain the release process of the AsyncAPI specification. This document aims to describe all details of the process so that any member of the community can jump in and help coordinate. +This document is meant to explain the release process of the AsyncAPI specification. It aims to describe all details of the process so that any member of the community can jump in and help coordinate. -## Release coordinator +It covers: +- **[Who?](#who)** - who is responsible for doing what in a release +- **[When?](#when)** - when releases happen +- **[What?](#what)** - what is covered by this document +- **[How?](#how)** - a description of the steps needed for a release -AsyncAPI specification release involves not only spec release but also the release of AsyncAPI-maintained tools. Therefore it requires a single person called `release coordinator` to ensure the release goes well throughout all phases. +--- +## Who? + +### "Release coordinator" + +AsyncAPI specification release involves not only spec release but also the release of AsyncAPI-maintained tools. Therefore it requires a single person called `release coordinator` to ensure the release goes well throughout all phases. The release coordinator is responsible for working through the process described below. The release coordinator doesn't have to do all the work alone. The release coordinator needs to find the right people to do the work required for a given phase and engage as many people as needed. -## Release cadence +Each release can have a different release coordinator. If you are interested and would like to know more, [join our Slack workspace](https://www.asyncapi.com/slack-invite) and visit the `11_how-to-contribute` channel. + +### Code owners + +Many of the steps needed to release a new version of the AsyncAPI specification (e.g. merging, creating branches, creating releases) need support from administrators for individual github.com/asyncapi repositories. + +Each respository contains a `CODEOWNERS` file (e.g. https://github.com/asyncapi/parser-js/blob/master/CODEOWNERS) that identifies the people who can help. + +--- +## When? + +### Release cadence AsyncAPI releases happen regularly in the following months: - January @@ -20,36 +40,165 @@ Regular releases concern only major and minor releases. We do not decide up fron Patch releases are automatically released and published. -## Release phases +### Release date philosophy + +The release is scheduled for a given month, not a specific day. We will release once everything is ready, and won't wait until the last day of the month with the release. + +We release often, so anything that isn't ready can wait until the next release (e.g. it can be released in June if the change will not make it in April). Our priority is the quality, and not quantity, of the features. Quality means that changes for a release is properly delivered in as many tools as possible with very good documentation and examples. + +--- +## What? + +### Repositories + +Github repositories that need to be updated at the same time to enable a release, in a coordinated way, are: +- [spec](https://github.com/asyncapi/spec) - the specification file +- [spec-json-schemas](https://github.com/asyncapi/spec-json-schemas) - the JSON schema +- [parser-js](https://github.com/asyncapi/parser-js) - the JavaScript parser +- [website](https://github.com/asyncapi/website) - the website + +--- +## How? + +The steps described here are not intended to be strictly chronological. For a single release, it might make sense to start some pieces of work in a slightly different order. The intention of the steps here is meant to give release coordinators a rough idea of the sequence involved. + +### Step 1 - kick off call + +A nice way to start a new release is to do one or more of the initial steps on an open live call/meeting. + +This isn't a required step, but possible benefits include: +- raising awareness of the upcoming release +- giving a new release coordinator support and initial direction to help them get started +- allowing potential future release coordinators to see what is involved + +Examples of arranging a contribution call like this can be found in the [community repository](https://github.com/asyncapi/community/issues?q=is%3Aissue+label%3Ameeting+contributor-first+) + + +### Step 2 - create a release issue + +To allow the community to see what is currently being considered for inclusion in a release, and to give easy, at-a-glance visibility over the progress, create a new Github issue in the [spec](https://github.com/asyncapi/spec) repository. + +This issue should be updated as each of the following steps are completed. + +A [template for a new release issue](https://github.com/asyncapi/spec/blob/master/.github/ISSUE_TEMPLATE/release.md) is available. -### Kick off +An example is the [release issue for the 2.3.0](https://github.com/asyncapi/spec/issues/675) release. -We start by creating release branches and a placeholder for release notes in the AsyncAPI Blog. +### Step 3 - create release branches -#### Release branch +Release branches must have a year and a month of the release as prefix: {YEAR_OF_RELEASE}-{MONTH_OF_RELEASE}-release. -At the beginning of the release cycle, we need to have a new release branch created in some repositories. The reason is that [contribution guide](CONTRIBUTING.md) for the specification requires changes in different projects to accept a proposal. The following repositories are involved: +For example, a release created in September 2021 has a `2021-09-release` release branch. + +This image shows part of the GitHub UI that shows how you can create a new branch using default branch as a base. + +At the beginning of the release cycle, we need to have a new release branch created in the following repositories: - [spec](https://github.com/asyncapi/spec) where contributor works with the specification file, - [spec-json-schemas](https://github.com/asyncapi/spec-json-schemas) where contributor pushes changes to JSON Schema of the spec, - [parser-js](https://github.com/asyncapi/parser-js) where contributor makes necessary changes in the JavaScript Parser. -Release branch must have a year and a month of the release as prefix: {YEAR_OF_RELEASE}-{MONTH_OF_RELEASE}-release. For example, a release created in September 2021 has a `2021-09-release` release branch. +The [release coordinator](#%22release-coordinator%22) should decide what the branch name needs to be, and contact the [code owners](#code-owners) for each repository to ask them to create the branches for them. -This image shows part of the GitHub UI that shows how you can create a new branch using default branch as a base. -Once feature branches are created, there must be some initial configuration done in each repository. +### Step 4 - update release branches + +Once [release branches are created](#step-3---create-release-branches), there are some initial changes that need to be made. + +The process for doing this is the same for each of these: +- the [release coordinator](#%22release-coordinator%22) should create a fork of the relevant repository for these changes +- the commit message for the change should start with `chore:` +- the change should be contributed in a pull request targeting the [release branch](#step-3---create-release-branches) +- the [release coordinator](#%22release-coordinator%22) will need to ask the [code owners](#code-owners) for the relevant repository to approve and merge this pull request + +#### Update version numbers in official examples +Repository: [spec](https://github.com/asyncapi/spec) + +Examples are located in the `examples/` folder in the [spec](https://github.com/asyncapi/spec) repository. They should all be updated to the new version number. + +An example of doing this is: +- this [commit from the 2.3.0 release](https://github.com/dalelane/spec/commit/8c521539cd875470ea8e89cf3ab7ffd81be64788) +- this [pull request from the 2.3.0 release](https://github.com/asyncapi/spec/pull/676) + +#### Create a new JSON schema file for the new version +Repository: [spec-json-schemas](https://github.com/asyncapi/spec-json-schemas) + +The new file should be created in the `schemas/` folder in the [spec-json-schemas](https://github.com/asyncapi/spec-json-schemas) repository. + +It should be named with the version of the new release, and a link should be added to the `index.js` file (in the same repository). + +An example of doing this is: +- this [commit from the 2.3.0 release](https://github.com/dalelane/spec-json-schemas/commit/9cff7798ac42f609927e1cb9e532ff16d360ab99) +- this [pull request from the 2.3.0 release](https://github.com/asyncapi/spec-json-schemas/pull/139) + +#### Update the list of AsyncAPI schema MIME types with the new version +Repository: [parser-js](https://github.com/asyncapi/parser-js) + +The file to be updated is `lib/asyncapiSchemaFormatParser.js` in the [parser-js](https://github.com/asyncapi/parser-js) repository. + +The new version number should be added to the list in the `getMimeTypes` function. + +An example of doing this is: +- this [pull request from the 2.3.0 release](https://github.com/asyncapi/parser-js/pull/426) + + +### Step 5 - update default branches + +Once [release branches have been updated](#step-4---update-release-branches), the default (e.g. "master") branches should be updated to identify the new release branch. + +The process for doing this is the same for each of these: +- the [release coordinator](#%22release-coordinator%22) should create a fork of the relevant repository for these changes (_this can be the same fork as used for updating the release branches_) +- the commit message for the change should start with `chore:` +- the change should be contributed in a pull request targeting the **default branch** (normally `master`) +- the [release coordinator](#%22release-coordinator%22) will need to ask the [code owners](#code-owners) for the relevant repository to approve and merge this pull request + +#### Update package.json files +There are **two** repositories where `package.json` files need to be updated. In both repositories, the release branch name needs to be updated in the list of branches under `.release.branches`. + +- [parser-js](https://github.com/asyncapi/parser-js/blob/master/package.json#L90-L93) +- [spec-json-schemas](https://github.com/asyncapi/spec-json-schemas/blob/master/package.json#L48-L51) -Things to do in release branch as `chore: ` changes: -- `spec` - Make sure all the official examples located in the repository use the new version of the specification, -- `spec-json-schemas` - Create new JSON Schema file with new version name and expose it here [here](https://github.com/asyncapi/spec-json-schemas/blob/master/index.js), -- `parser-js` - Make sure the list of supported AsyncAPI schema MIME types is extended with the new version [here](https://github.com/asyncapi/parser-js/blob/master/lib/asyncapiSchemaFormatParser.js#L43.) +Examples of doing this are: +- this [commit from the 2.3.0 release for parser-js](https://github.com/dalelane/parser-js/commit/1d9f9ed52718269ffbce4d32bd4635c690371f80) +- this [commit from the 2.3.0 release for spec-json-schemas](https://github.com/dalelane/spec-json-schemas/commit/8a4b94aaf86240a6ca2aeb7ce3cc515bad283a2d) + + +#### Update .releaserc file +The release branch name needs to be updated in the `.releaserc` file in the [spec](https://github.com/asyncapi/spec) repository needs. + +An example of doing this is: +- this [commit from the 2.3.0 release](https://github.com/dalelane/spec/commit/210f89adc74f17aaf09d808b84132f232ff2e412) + + +### Step 6 - prepare announcement blog post + +Each new release is announced by a blog post. You can see all of these at https://www.asyncapi.com/blog?tags=Release+Notes + +The [release coordinator](#%22release-coordinator%22) should create an empty placeholder blog post that can be added to by different contributors to the release throughout the release process. + +The steps to follow for this are: +- Create a fork of the [website](https://github.com/asyncapi/website) repository +- Create a new file at `pages/blog/release-notes-X.X.X.md` (replacing `X.X.X` with the version number for the release) +- Add a standard header at the top of the file (see the release notes for [2.2.0](https://raw.githubusercontent.com/asyncapi/website/master/pages/blog/release-notes-2.2.0.md) and [2.3.0](https://raw.githubusercontent.com/asyncapi/website/master/pages/blog/release-notes-2.3.0.md) for examples) +- Add a (webp format) cover image to the `public/img/posts/release-notes-X.X.X/` folder, and update the `cover` attribute of the blog post header with it. (**Make sure to attribute the image correctly** - unsplash.com is a good source of free images for this). See [this commit from the 2.3.0 release](4050ca0540684f5188300e0c27efc713a6ba1ec2) for an example of doing this. +- Add a (webp format) profile picture of the release coordinator to the `public/img/avatars` folder, and update the `authors` attribute of the blog post header with it. See [this commit from the 2.3.0 release](https://github.com/asyncapi/website/pull/512/commits/006f7df26b0d0803ed2e1dd6b8004dfdaec15617) for an example of doing this. +- Open a **draft** pull request against the [website](https://github.com/asyncapi/website/) repository. Make sure the option **Allow edits and access to secrets by maintainers** is selected to enable support from maintainers. +This image shows example pull request created in GitHub with release notes for AsyncAPI specification + +### Step 7 - bring updates into release branch + +seek out possible updates that are viable candidates for the release + +look through open pull requests in the three core repos + +pull requests from feature branches into release branch(es) + +- Open draft pull requests in all repositories required by the contribution guide. They should point from the release branch in the upstream to the master branch in the upstream, + + +### Step 8 - update announcement blog post + +- Update previously created draft of release notes with information about the new feature. Collaborate closely with feature contributors, -Things to do in default branch and release branch as `chore: ` changes: -- Set release branch name in prerelease configuration in some repos repositories: - - [package.json in parser-js](https://github.com/asyncapi/parser-js/blob/master/package.json#L90) - - [package.json in spec-json-schemas](https://github.com/asyncapi/spec-json-schemas/blob/master/package.json#L49) - - [.releaserc in spec](https://github.com/asyncapi/spec/blob/master/.releaserc#L4) -#### Release notes Changes in the specification need to be well described. We need clear information on what has changed, why, and who contributed to the change. A regular changelog is not enough as it is not user-friendly. Every release must have release notes. @@ -57,15 +206,18 @@ A draft pull request with release notes must be opened at the same time release In other words, once a feature is introduced in the release branch, make sure it is properly described in release notes. -The draft pull request must be opened against the [Website](https://github.com/asyncapi/website/) repository. Make sure the option `Allow edits and access to secrets by maintainers` is selected to enable support from maintainers. -This image shows example pull request created in GitHub with release notes for AsyncAPI specification -### Review and merge +### Step 9 - prepare release notes + +markdown version for releases in git -There are no step-by-step instructions to follow but a set of rules. +### Step 10 - notify people the release is coming -#### Review +meetings +slack + +### Step 11 - reviews - Everybody is invited to perform a review of proposals. The [contribution guide](CONTRIBUTING.md) describes all requirements proposal needs to fulfill to reach `Stage 3: Accepted`, - Pull request must be: @@ -74,38 +226,50 @@ There are no step-by-step instructions to follow but a set of rules. - created in all repositories specified in contribution guide, - At least one user listed in [CODEOWNERS](CODEOWNERS) must approve the pull request in all related repositories. -#### Merge + +### Step 12 - release candidates + +_how is this done?_ + +### Step 13 - merge the release branches - Merge can be done only by repository [CODEOWNERS](CODEOWNERS), - Every pull request must have a `feat: ` prefix that, after the merge, produces a release candidate with a minor version update. The major version must have `feat!: ` prefix, - Pull request in the `parser-js` can be merged only if it uses the release candidate of `@asyncapi/specs` package produced after merge of a pull request in `spec-json-schemas`, - First, changes are merged into the `spec` repository, then `spec-json-schemas` and then in `parser-js`. -### Next steps +- Release means merge of pull requests created from a release branch against the master branch. First, changes are merged into the `spec` repository, then `spec-json-schemas` and at the end in `parser-js`. Like in the case of the merge of release candidates, a pull request in `parser-js` can be merged only if it uses the final release of the new `@asyncapi/specs` package. + +### Step 14 - publish releases + + +- Merge release notes and once they are published, link them under the GitHub release for the specification, like [here](https://github.com/asyncapi/spec/releases/tag/v2.1.0). + + +### Step 15 - update website + +- Update documentation in [website](https://github.com/asyncapi/website) to promote latest version of the specification. You can do it in the same pull request with release notes. No need to care for the specification markdown file on the Website. It updates automatically during work on release candidates and also after the final release. + + +### Step 16 - notify tool maintainers + -- Update previously created draft of release notes with information about the new feature. Collaborate closely with feature contributors, - Notify maintainers of the following repositories that the first feature is merged and that release will be produced and therefore they need to start preparing for it: - [JavaScript Converter](https://github.com/asyncapi/converter-js/) - [Playground](https://github.com/asyncapi/playground/) - [React component](https://github.com/asyncapi/asyncapi-react/) - [Markdown template](https://github.com/asyncapi/markdown-template) -### Steps only after first feature merge +- Make sure other maintainers from other projects under the AsyncAPI GitHub organization released their packages -- Open draft pull requests in all repositories required by the contribution guide. They should point from the release branch in the upstream to the master branch in the upstream, -- Update documentation in [website](https://github.com/asyncapi/website) to promote latest version of the specification. You can do it in the same pull request with release notes. No need to care for the specification markdown file on the Website. It updates automatically during work on release candidates and also after the final release. -#### Communication +### Step 17 - notify the community Every release of the release candidate is automatically published on the AsyncAPI Twitter account and in the releases-dedicated Slack channel. Feel free to use other communication channels. Make sure that as many people as possible know about the change. Feel free to contact vendors upfront or other people that are interested in changes in the specification. -### Ship it! +- Make sure proper communication is sent from all the official AsyncAPI social accounts and on Slack -The release is scheduled for a given month, not a specific day. You do not have to wait until the last day of the month with the release. We release often, so it can be released in June if the change will not make it in April. Most important is the quality and not quantity of the features. The quality feature means it is properly delivered in as many tools as possible with very good documentation and examples. -- Release means merge of pull requests created from a release branch against the master branch. First, changes are merged into the `spec` repository, then `spec-json-schemas` and at the end in `parser-js`. Like in the case of the merge of release candidates, a pull request in `parser-js` can be merged only if it uses the final release of the new `@asyncapi/specs` package. -- Make sure other maintainers from other projects under the AsyncAPI GitHub organization released their packages -- Merge release notes and once they are published, link them under the GitHub release for the specification, like [here](https://github.com/asyncapi/spec/releases/tag/v2.1.0). -- Make sure proper communication is sent from all the official AsyncAPI social accounts and on Slack +### Step 18 - improve the release process -Now relax as the next release is right behind the corner :smiley: +update this doc, and the release issue template From c555dbf7728b04cf8bda8a2db32bf5294d94219e Mon Sep 17 00:00:00 2001 From: Dale Lane Date: Thu, 10 Feb 2022 15:30:58 +0000 Subject: [PATCH 02/14] wip --- RELEASE_PROCESS.md | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/RELEASE_PROCESS.md b/RELEASE_PROCESS.md index e9504b12..b42d886e 100644 --- a/RELEASE_PROCESS.md +++ b/RELEASE_PROCESS.md @@ -184,6 +184,9 @@ The steps to follow for this are: - Open a **draft** pull request against the [website](https://github.com/asyncapi/website/) repository. Make sure the option **Allow edits and access to secrets by maintainers** is selected to enable support from maintainers. This image shows example pull request created in GitHub with release notes for AsyncAPI specification +An example of doing this is: +- this [pull request from the 2.3.0 release](https://github.com/asyncapi/website/pull/512) + ### Step 7 - bring updates into release branch seek out possible updates that are viable candidates for the release @@ -192,12 +195,16 @@ look through open pull requests in the three core repos pull requests from feature branches into release branch(es) -- Open draft pull requests in all repositories required by the contribution guide. They should point from the release branch in the upstream to the master branch in the upstream, +- Everybody is invited to perform a review of proposals. The [contribution guide](CONTRIBUTING.md) describes all requirements proposal needs to fulfill to reach `Stage 3: Accepted`, +- Pull request must be: + - labeled as an accepted proposal, + - created against the feature branch, + - created in all repositories specified in contribution guide, ### Step 8 - update announcement blog post -- Update previously created draft of release notes with information about the new feature. Collaborate closely with feature contributors, +Update previously created draft of release notes with information about the new feature. Collaborate closely with feature contributors, Changes in the specification need to be well described. We need clear information on what has changed, why, and who contributed to the change. A regular changelog is not enough as it is not user-friendly. Every release must have release notes. @@ -219,11 +226,8 @@ slack ### Step 11 - reviews -- Everybody is invited to perform a review of proposals. The [contribution guide](CONTRIBUTING.md) describes all requirements proposal needs to fulfill to reach `Stage 3: Accepted`, -- Pull request must be: - - labeled as an accepted proposal, - - created against the feature branch, - - created in all repositories specified in contribution guide, +- Open draft pull requests in all repositories required by the contribution guide. They should point from the release branch in the upstream to the master branch in the upstream, + - At least one user listed in [CODEOWNERS](CODEOWNERS) must approve the pull request in all related repositories. From 2560884651625c524db1b24481e3ce70c634c10d Mon Sep 17 00:00:00 2001 From: Dale Lane Date: Sat, 12 Feb 2022 14:39:52 +0000 Subject: [PATCH 03/14] wip --- RELEASE_PROCESS.md | 100 +++++++++++++++++++++++++++++---------------- 1 file changed, 65 insertions(+), 35 deletions(-) diff --git a/RELEASE_PROCESS.md b/RELEASE_PROCESS.md index b42d886e..b8def61e 100644 --- a/RELEASE_PROCESS.md +++ b/RELEASE_PROCESS.md @@ -187,75 +187,105 @@ The steps to follow for this are: An example of doing this is: - this [pull request from the 2.3.0 release](https://github.com/asyncapi/website/pull/512) -### Step 7 - bring updates into release branch -seek out possible updates that are viable candidates for the release +### Step 7 - create draft pull requests -look through open pull requests in the three core repos +Draft pull requests should be opened for all [repositories covered by this process](#repositories). -pull requests from feature branches into release branch(es) +They should point from the [release branches](#step-3---create-release-branches) to the default/master branches for each repository. -- Everybody is invited to perform a review of proposals. The [contribution guide](CONTRIBUTING.md) describes all requirements proposal needs to fulfill to reach `Stage 3: Accepted`, -- Pull request must be: - - labeled as an accepted proposal, - - created against the feature branch, - - created in all repositories specified in contribution guide, +### Step 8 - bring updates into release branch -### Step 8 - update announcement blog post +The [release coordinator](#%22release-coordinator%22) should help to seek out possible updates that are goood candidates for including in the release. -Update previously created draft of release notes with information about the new feature. Collaborate closely with feature contributors, +There are lots of ways to do this: +- ask for contributions in [Slack](https://www.asyncapi.com/slack-invite) +- ask for suggestions at a [community meeting](https://github.com/asyncapi/community/issues?q=is%3Aissue+is%3Aopen+label%3Ameeting) +- look for open accepted issues (see the [contribution guide](CONTRIBUTING.md) for a description of the requirements for a proposal to reach `Stage 3: Accepted`) +- look for open pull requests in the [repositories covered by this process](#repositories) +For each feature that is being brought into the release, a pull request should be created from the feature branch (the branch with the accepted changes in) to the [release branch](#step-3---create-release-branches). -Changes in the specification need to be well described. We need clear information on what has changed, why, and who contributed to the change. A regular changelog is not enough as it is not user-friendly. Every release must have release notes. +Pull requests must be: +- labeled as an accepted proposal, +- created against the feature branch, +- created in all repositories specified in contribution guide -A draft pull request with release notes must be opened at the same time release branches are created. Work on release notes should be done on a feature-by-feature basis and not at the end of the release cycle. Cooperate with contributors. They should be able to provide input and also be allowed to work as release notes article co-authors. -In other words, once a feature is introduced in the release branch, make sure it is properly described in release notes. +### Step 9 - update announcement blog post +As features are identified for inclusion in the release, the [draft announcement blog post](#step-6---prepare-announcement-blog-post) should be updated with descriptions of them. The [release cooordinator](#%22release-coordinator%22) should coordinate with the feature contributors to write a description of each change. They should be able to provide input and also be allowed to work as co-authors for the release notes post. +Changes in the specification need to be well described. We need clear information on what has changed, why, and who contributed to the change. The purpose of the announcement blog post is to be a more user-friendly alternative to a regular changelog. -### Step 9 - prepare release notes +Every feature added to the [release branch](#step-3---create-release-branches) needs to be properly described in the release notes post. -markdown version for releases in git -### Step 10 - notify people the release is coming +### Step 10 - prepare release notes -meetings -slack +In addition to the [announcement blog post](#step-9---update-announcement-blog-post), the [release coordinator](#%22release-coordinator%22) should prepare release notes for each of the [repositories covered by this process](#repositories). -### Step 11 - reviews +These should: +- be written in markdown +- include a list of features and significant changes +- include a link to github issues and pull requests where more background can be found +- include a link to a github diff with the previous release + +Examples of doing this are: +- the [release notes for version 2.3.0 of spec](https://github.com/asyncapi/spec/releases/tag/v2.3.0) + + +### Step 11 - notify people the release is coming + +As the release gets closer to being ready, it is helpful to remind the community that the release is on the way. + +This can be done: +- in [Slack](https://www.asyncapi.com/slack-invite) +- at [community meetings](https://github.com/asyncapi/community/issues?q=is%3Aissue+is%3Aopen+label%3Ameeting) + +Including a link to the [release issue](#step-2---create-a-release-issue) is a good way to let the community see the progress that has been made so far. -- Open draft pull requests in all repositories required by the contribution guide. They should point from the release branch in the upstream to the master branch in the upstream, -- At least one user listed in [CODEOWNERS](CODEOWNERS) must approve the pull request in all related repositories. +### Step 12 - reviews +At least one [code owner](#code-owners) must approve the [release pull requests](#step-7---create-draft-pull-requests) in all related [repositories](#repositories). -### Step 12 - release candidates + +### Step 13 - release candidates _how is this done?_ -### Step 13 - merge the release branches +Example release candidate +https://github.com/asyncapi/spec-json-schemas/pull/151 + + +### Step 14 - merge the release branches + +Once everything is ready, it is time to merge the [release branches](#step-3---create-release-branches) using the [draft pull requests prepared earlier](#step-7---create-draft-pull-requests). + +Merging can only be done by [code owners](#code-owners). + +Pull requests must have a `feat: ` prefix that, after the merge, produces a release candidate with a minor version update. The major version must have `feat!: ` prefix. + +Pull requests in the `parser-js` can be merged only if it uses the release candidate of `@asyncapi/specs` package produced after merge of a pull request in `spec-json-schemas`. -- Merge can be done only by repository [CODEOWNERS](CODEOWNERS), -- Every pull request must have a `feat: ` prefix that, after the merge, produces a release candidate with a minor version update. The major version must have `feat!: ` prefix, -- Pull request in the `parser-js` can be merged only if it uses the release candidate of `@asyncapi/specs` package produced after merge of a pull request in `spec-json-schemas`, -- First, changes are merged into the `spec` repository, then `spec-json-schemas` and then in `parser-js`. +First, changes are merged into the `spec` repository, then `spec-json-schemas` and then in `parser-js`. -- Release means merge of pull requests created from a release branch against the master branch. First, changes are merged into the `spec` repository, then `spec-json-schemas` and at the end in `parser-js`. Like in the case of the merge of release candidates, a pull request in `parser-js` can be merged only if it uses the final release of the new `@asyncapi/specs` package. +Release means merge of pull requests created from a release branch against the master branch. First, changes are merged into the `spec` repository, then `spec-json-schemas` and at the end in `parser-js`. Like in the case of the merge of release candidates, a pull request in `parser-js` can be merged only if it uses the final release of the new `@asyncapi/specs` package. -### Step 14 - publish releases +### Step 15 - publish releases -- Merge release notes and once they are published, link them under the GitHub release for the specification, like [here](https://github.com/asyncapi/spec/releases/tag/v2.1.0). +The [release coordinator](#%22release-coordinator%22) should ask the [code owners](#code-owners) for each repository to create the release in Github, using the [release notes they have prepared](#step-10---prepare-release-notes). -### Step 15 - update website +### Step 16 - update website - Update documentation in [website](https://github.com/asyncapi/website) to promote latest version of the specification. You can do it in the same pull request with release notes. No need to care for the specification markdown file on the Website. It updates automatically during work on release candidates and also after the final release. -### Step 16 - notify tool maintainers +### Step 17 - notify tool maintainers - Notify maintainers of the following repositories that the first feature is merged and that release will be produced and therefore they need to start preparing for it: @@ -267,13 +297,13 @@ _how is this done?_ - Make sure other maintainers from other projects under the AsyncAPI GitHub organization released their packages -### Step 17 - notify the community +### Step 18 - notify the community Every release of the release candidate is automatically published on the AsyncAPI Twitter account and in the releases-dedicated Slack channel. Feel free to use other communication channels. Make sure that as many people as possible know about the change. Feel free to contact vendors upfront or other people that are interested in changes in the specification. - Make sure proper communication is sent from all the official AsyncAPI social accounts and on Slack -### Step 18 - improve the release process +### Step 19 - improve the release process update this doc, and the release issue template From 86e98dbb0a63e1a27c66861cf95999225b40ccaf Mon Sep 17 00:00:00 2001 From: Dale Lane Date: Sat, 12 Feb 2022 14:50:31 +0000 Subject: [PATCH 04/14] wip --- RELEASE_PROCESS.md | 32 ++++++++++++++++++++------------ 1 file changed, 20 insertions(+), 12 deletions(-) diff --git a/RELEASE_PROCESS.md b/RELEASE_PROCESS.md index b8def61e..d51a1782 100644 --- a/RELEASE_PROCESS.md +++ b/RELEASE_PROCESS.md @@ -119,6 +119,16 @@ An example of doing this is: - this [commit from the 2.3.0 release](https://github.com/dalelane/spec/commit/8c521539cd875470ea8e89cf3ab7ffd81be64788) - this [pull request from the 2.3.0 release](https://github.com/asyncapi/spec/pull/676) +#### Update version number in the spec +Repository: [spec](https://github.com/asyncapi/spec) + +References to the latest version in `spec/asyncapi.md` should be updated to the new version number. + +Examples of doing this are: +- this [commit from the 2.3.0 release](https://github.com/asyncapi/spec/commit/1f29d803ca801756d4ea3f676bcf7e7751478de6) +- this [commit from the 2.3.0 release](https://github.com/asyncapi/spec/commit/7f827a880fa3ddcbc9a39d50e41502bc450443bc) + + #### Create a new JSON schema file for the new version Repository: [spec-json-schemas](https://github.com/asyncapi/spec-json-schemas) @@ -280,30 +290,28 @@ Release means merge of pull requests created from a release branch against the m The [release coordinator](#%22release-coordinator%22) should ask the [code owners](#code-owners) for each repository to create the release in Github, using the [release notes they have prepared](#step-10---prepare-release-notes). -### Step 16 - update website +### Step 16 - notify tool maintainers -- Update documentation in [website](https://github.com/asyncapi/website) to promote latest version of the specification. You can do it in the same pull request with release notes. No need to care for the specification markdown file on the Website. It updates automatically during work on release candidates and also after the final release. - - -### Step 17 - notify tool maintainers - - -- Notify maintainers of the following repositories that the first feature is merged and that release will be produced and therefore they need to start preparing for it: +The [release coordinator](#%22release-coordinator%22) should notify maintainers of the following repositories that the first feature is merged and that release will be produced and therefore they need to start preparing for it: - [JavaScript Converter](https://github.com/asyncapi/converter-js/) - [Playground](https://github.com/asyncapi/playground/) - [React component](https://github.com/asyncapi/asyncapi-react/) - [Markdown template](https://github.com/asyncapi/markdown-template) -- Make sure other maintainers from other projects under the AsyncAPI GitHub organization released their packages +The [release coordinator](#%22release-coordinator%22) should also make sure other maintainers from other projects under the AsyncAPI GitHub organization released their packages. ### Step 18 - notify the community -Every release of the release candidate is automatically published on the AsyncAPI Twitter account and in the releases-dedicated Slack channel. Feel free to use other communication channels. Make sure that as many people as possible know about the change. Feel free to contact vendors upfront or other people that are interested in changes in the specification. +Every release of the release candidate is automatically published on the AsyncAPI Twitter account and in the releases-dedicated Slack channel. + +Feel free to use other communication channels. Make sure that as many people as possible know about the change. Feel free to contact vendors upfront or other people that are interested in changes in the specification. -- Make sure proper communication is sent from all the official AsyncAPI social accounts and on Slack +Make sure proper communication is sent from all the official AsyncAPI social accounts and on Slack ### Step 19 - improve the release process -update this doc, and the release issue template +Every release identifies new issues and ways that the process can be improved. + +Once the release is complete, the final step is to update this document with anything that could have gone better! From 5259fb341e7701a1de35956e271fe32c8f9ef8ad Mon Sep 17 00:00:00 2001 From: Dale Lane Date: Sat, 12 Feb 2022 15:00:13 +0000 Subject: [PATCH 05/14] wip --- .github/ISSUE_TEMPLATE/release.md | 61 +++++++++++++++++++++++++++++++ RELEASE_PROCESS.md | 4 +- 2 files changed, 63 insertions(+), 2 deletions(-) create mode 100644 .github/ISSUE_TEMPLATE/release.md diff --git a/.github/ISSUE_TEMPLATE/release.md b/.github/ISSUE_TEMPLATE/release.md new file mode 100644 index 00000000..85a923bc --- /dev/null +++ b/.github/ISSUE_TEMPLATE/release.md @@ -0,0 +1,61 @@ +--- +name: Release issue +about: Create a report to help us improve +title: "" +labels: ':shipit: Release' +assignees: '' +--- + +Release X.X.X is scheduled for XXXX + +### Detailed info: +* https://github.com/asyncapi/spec/blob/master/RELEASE_PROCESS.md + +### Kick-off: +* _link to recording of community call where the new release was started_ + +### Release branches: +* https://github.com/asyncapi/spec/tree/BRANCH_NAME +* https://github.com/asyncapi/spec-json-schemas/tree/BRANCH_NAME +* https://github.com/asyncapi/parser-js/tree/BRANCH_NAME + +### Release notes: +* 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 + - [] spec-json-schemas + - [] parser-js +- [] Update default branches with release branch name + - [] spec + - [] spec-json-schemas + - [] parser-js +- [] Create draft release notes +- [] Update release branches from forks + - [] spec + - [] spec-json-schemas + - [] parser-js +- [] 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 diff --git a/RELEASE_PROCESS.md b/RELEASE_PROCESS.md index d51a1782..5126b6c5 100644 --- a/RELEASE_PROCESS.md +++ b/RELEASE_PROCESS.md @@ -301,7 +301,7 @@ The [release coordinator](#%22release-coordinator%22) should notify maintainers The [release coordinator](#%22release-coordinator%22) should also make sure other maintainers from other projects under the AsyncAPI GitHub organization released their packages. -### Step 18 - notify the community +### Step 17 - notify the community Every release of the release candidate is automatically published on the AsyncAPI Twitter account and in the releases-dedicated Slack channel. @@ -310,7 +310,7 @@ Feel free to use other communication channels. Make sure that as many people as Make sure proper communication is sent from all the official AsyncAPI social accounts and on Slack -### Step 19 - improve the release process +### Step 18 - improve the release process Every release identifies new issues and ways that the process can be improved. From a25076ff90e794b24681ca0ebb4b4ac78837edda Mon Sep 17 00:00:00 2001 From: Dale Lane Date: Sat, 12 Feb 2022 15:20:42 +0000 Subject: [PATCH 06/14] docs: update .github/ISSUE_TEMPLATE/release.md --- .github/ISSUE_TEMPLATE/release.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/ISSUE_TEMPLATE/release.md b/.github/ISSUE_TEMPLATE/release.md index 85a923bc..2b9a3699 100644 --- a/.github/ISSUE_TEMPLATE/release.md +++ b/.github/ISSUE_TEMPLATE/release.md @@ -1,6 +1,6 @@ --- name: Release issue -about: Create a report to help us improve +about: Track the progress of the next release of the AsyncAPI spec title: "" labels: ':shipit: Release' assignees: '' From dd6c40cb304147efdff2c743758ccaee1faad184 Mon Sep 17 00:00:00 2001 From: Dale Lane Date: Mon, 14 Mar 2022 22:03:24 +0000 Subject: [PATCH 07/14] fix: fix markdown in template --- .github/ISSUE_TEMPLATE/release.md | 50 +++++++++++++++---------------- 1 file changed, 25 insertions(+), 25 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/release.md b/.github/ISSUE_TEMPLATE/release.md index 2b9a3699..f221a18b 100644 --- a/.github/ISSUE_TEMPLATE/release.md +++ b/.github/ISSUE_TEMPLATE/release.md @@ -23,31 +23,31 @@ Release X.X.X is scheduled for XXXX * 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 - - [] spec-json-schemas - - [] parser-js -- [] Update default branches with release branch name - - [] spec - - [] spec-json-schemas - - [] parser-js -- [] Create draft release notes -- [] Update release branches from forks - - [] spec - - [] spec-json-schemas - - [] parser-js -- [] 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 +- [ ] Create release branches + - [ ] spec + - [ ] spec-json-schemas + - [ ] parser-js +- [ ] Update release branches with new versions + - [ ] spec + - [ ] spec-json-schemas + - [ ] parser-js +- [ ] Update default branches with release branch name + - [ ] spec + - [ ] spec-json-schemas + - [ ] parser-js +- [ ] Create draft release notes +- [ ] Update release branches from forks + - [ ] spec + - [ ] spec-json-schemas + - [ ] parser-js +- [ ] 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 From 9ec346085b27669bc3957562d356309daf225614 Mon Sep 17 00:00:00 2001 From: Dale Lane Date: Mon, 14 Mar 2022 22:10:34 +0000 Subject: [PATCH 08/14] docs: address review comments --- RELEASE_PROCESS.md | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/RELEASE_PROCESS.md b/RELEASE_PROCESS.md index 5126b6c5..6de8f287 100644 --- a/RELEASE_PROCESS.md +++ b/RELEASE_PROCESS.md @@ -198,16 +198,22 @@ An example of doing this is: - this [pull request from the 2.3.0 release](https://github.com/asyncapi/website/pull/512) -### Step 7 - create draft pull requests +### Step 7 - create pull requests -Draft pull requests should be opened for all [repositories covered by this process](#repositories). +Pull requests should be opened for all [repositories covered by this process](#repositories). + +These should be full, not draft, pull requests to allow automated tests to run. They should point from the [release branches](#step-3---create-release-branches) to the default/master branches for each repository. +Add a **do-not-merge** label to the pull request by making a comment in the PR saying `/dnm`. + +_Note: The automation bot will keep the release branch up to date with the latest commits from the master branch (so long as there are no conflicts)._ + ### Step 8 - bring updates into release branch -The [release coordinator](#%22release-coordinator%22) should help to seek out possible updates that are goood candidates for including in the release. +The [release coordinator](#%22release-coordinator%22) should help to seek out possible updates that are good candidates for including in the release. There are lots of ways to do this: - ask for contributions in [Slack](https://www.asyncapi.com/slack-invite) @@ -259,7 +265,7 @@ Including a link to the [release issue](#step-2---create-a-release-issue) is a g ### Step 12 - reviews -At least one [code owner](#code-owners) must approve the [release pull requests](#step-7---create-draft-pull-requests) in all related [repositories](#repositories). +At least one [code owner](#code-owners) must approve the [release pull requests](#step-7---create-pull-requests) in all related [repositories](#repositories). ### Step 13 - release candidates @@ -272,7 +278,7 @@ https://github.com/asyncapi/spec-json-schemas/pull/151 ### Step 14 - merge the release branches -Once everything is ready, it is time to merge the [release branches](#step-3---create-release-branches) using the [draft pull requests prepared earlier](#step-7---create-draft-pull-requests). +Once everything is ready, it is time to merge the [release branches](#step-3---create-release-branches) using the [draft pull requests prepared earlier](#step-7---create-pull-requests). Merging can only be done by [code owners](#code-owners). From c4df41069e69a42c41313e8b54bbe651333a2a0d Mon Sep 17 00:00:00 2001 From: Dale Lane Date: Mon, 14 Mar 2022 22:11:43 +0000 Subject: [PATCH 09/14] docs: address review comment --- RELEASE_PROCESS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/RELEASE_PROCESS.md b/RELEASE_PROCESS.md index 6de8f287..0afc5610 100644 --- a/RELEASE_PROCESS.md +++ b/RELEASE_PROCESS.md @@ -257,7 +257,7 @@ Examples of doing this are: As the release gets closer to being ready, it is helpful to remind the community that the release is on the way. This can be done: -- in [Slack](https://www.asyncapi.com/slack-invite) +- in the `#specification` channel in [Slack](https://www.asyncapi.com/slack-invite) - at [community meetings](https://github.com/asyncapi/community/issues?q=is%3Aissue+is%3Aopen+label%3Ameeting) Including a link to the [release issue](#step-2---create-a-release-issue) is a good way to let the community see the progress that has been made so far. From bc7278b3950c02d562ddc2d6db6920635a58dc0f Mon Sep 17 00:00:00 2001 From: Dale Lane Date: Mon, 14 Mar 2022 22:19:54 +0000 Subject: [PATCH 10/14] docs: add release candidate explanation --- RELEASE_PROCESS.md | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/RELEASE_PROCESS.md b/RELEASE_PROCESS.md index 0afc5610..7f43c134 100644 --- a/RELEASE_PROCESS.md +++ b/RELEASE_PROCESS.md @@ -270,10 +270,20 @@ At least one [code owner](#code-owners) must approve the [release pull requests] ### Step 13 - release candidates -_how is this done?_ +Pre-release release candidates are generated automatically by the automation bot when: +- a pull request with a **fix** or **feat** prefix in the title is merged into the [release branch](#step-3---create-release-branches) -Example release candidate -https://github.com/asyncapi/spec-json-schemas/pull/151 +An example of a pull request created by the automation bot is: https://github.com/asyncapi/spec-json-schemas/pull/151 + +Release candidates will include: +- upcoming release number +- date of the release +- release candidate number + +An example release candidate is: https://github.com/asyncapi/spec/releases/tag/v2.3.0-2022-01-release.3 + + +**Important:** When release candidates are created for the [spec](https://github.com/asyncapi/spec) repository, the [parser-js](https://github.com/asyncapi/parser-js) repository will need to be updated to use that release candidate. ### Step 14 - merge the release branches From 5d77424198f2b589edf3fa1bea8af98fc6e787c2 Mon Sep 17 00:00:00 2001 From: Dale Lane Date: Mon, 14 Mar 2022 22:21:35 +0000 Subject: [PATCH 11/14] docs: address review comments --- RELEASE_PROCESS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/RELEASE_PROCESS.md b/RELEASE_PROCESS.md index 7f43c134..884d42c3 100644 --- a/RELEASE_PROCESS.md +++ b/RELEASE_PROCESS.md @@ -303,7 +303,7 @@ Release means merge of pull requests created from a release branch against the m ### Step 15 - publish releases -The [release coordinator](#%22release-coordinator%22) should ask the [code owners](#code-owners) for each repository to create the release in Github, using the [release notes they have prepared](#step-10---prepare-release-notes). +The [release coordinator](#%22release-coordinator%22) should ask the [code owners](#code-owners) for each repository to update the release in Github created by the automation bot, by adding the [release notes they have prepared](#step-10---prepare-release-notes). ### Step 16 - notify tool maintainers From 71905b3089c56fca10a57dc8b3805f3ba390b5ce Mon Sep 17 00:00:00 2001 From: Dale Lane Date: Mon, 14 Mar 2022 22:26:43 +0000 Subject: [PATCH 12/14] docs: address review comments --- RELEASE_PROCESS.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/RELEASE_PROCESS.md b/RELEASE_PROCESS.md index 884d42c3..0f5fff57 100644 --- a/RELEASE_PROCESS.md +++ b/RELEASE_PROCESS.md @@ -321,9 +321,9 @@ The [release coordinator](#%22release-coordinator%22) should also make sure othe Every release of the release candidate is automatically published on the AsyncAPI Twitter account and in the releases-dedicated Slack channel. -Feel free to use other communication channels. Make sure that as many people as possible know about the change. Feel free to contact vendors upfront or other people that are interested in changes in the specification. +If the [release coordinator](#%22release-coordinator%22) uses social networks like Twitter or LinkedIn, it is a great idea for them to promote the work that they've done to prepare the release by announcing it on their own private accounts. These can then be promoted and shared from the official AsyncAPI social accounts, to highlight and demonstrate the community-driven nature of releases. -Make sure proper communication is sent from all the official AsyncAPI social accounts and on Slack +Feel free to use other communication channels. Make sure that as many people as possible know about the change. Feel free to contact vendors upfront or other people that are interested in changes in the specification. ### Step 18 - improve the release process From 6614fb176344bc2464e2005c9c6a35fed1f61b60 Mon Sep 17 00:00:00 2001 From: Dale Lane Date: Mon, 14 Mar 2022 22:32:07 +0000 Subject: [PATCH 13/14] docs: address review comments --- RELEASE_PROCESS.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/RELEASE_PROCESS.md b/RELEASE_PROCESS.md index 0f5fff57..d27cf5c1 100644 --- a/RELEASE_PROCESS.md +++ b/RELEASE_PROCESS.md @@ -256,7 +256,9 @@ Examples of doing this are: As the release gets closer to being ready, it is helpful to remind the community that the release is on the way. -This can be done: +A good way to do this is to mention code owners and community tool maintainers in the [release issue](#step-2---create-a-release-issue) to draw their attention to it. + +This can also be done: - in the `#specification` channel in [Slack](https://www.asyncapi.com/slack-invite) - at [community meetings](https://github.com/asyncapi/community/issues?q=is%3Aissue+is%3Aopen+label%3Ameeting) From 7df9d6d8ec46c66fc1f8835be3b974e88a44a269 Mon Sep 17 00:00:00 2001 From: Dale Lane Date: Tue, 15 Mar 2022 17:30:13 +0000 Subject: [PATCH 14/14] docs: address review comment --- RELEASE_PROCESS.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/RELEASE_PROCESS.md b/RELEASE_PROCESS.md index d27cf5c1..e924ea33 100644 --- a/RELEASE_PROCESS.md +++ b/RELEASE_PROCESS.md @@ -110,7 +110,7 @@ The process for doing this is the same for each of these: - the change should be contributed in a pull request targeting the [release branch](#step-3---create-release-branches) - the [release coordinator](#%22release-coordinator%22) will need to ask the [code owners](#code-owners) for the relevant repository to approve and merge this pull request -#### Update version numbers in official examples +#### Step 4.1 - Update version numbers in official examples Repository: [spec](https://github.com/asyncapi/spec) Examples are located in the `examples/` folder in the [spec](https://github.com/asyncapi/spec) repository. They should all be updated to the new version number. @@ -119,7 +119,7 @@ An example of doing this is: - this [commit from the 2.3.0 release](https://github.com/dalelane/spec/commit/8c521539cd875470ea8e89cf3ab7ffd81be64788) - this [pull request from the 2.3.0 release](https://github.com/asyncapi/spec/pull/676) -#### Update version number in the spec +#### Step 4.2 - Update version number in the spec Repository: [spec](https://github.com/asyncapi/spec) References to the latest version in `spec/asyncapi.md` should be updated to the new version number. @@ -129,7 +129,7 @@ Examples of doing this are: - this [commit from the 2.3.0 release](https://github.com/asyncapi/spec/commit/7f827a880fa3ddcbc9a39d50e41502bc450443bc) -#### Create a new JSON schema file for the new version +#### Step 4.3 - Create a new JSON schema file for the new version Repository: [spec-json-schemas](https://github.com/asyncapi/spec-json-schemas) The new file should be created in the `schemas/` folder in the [spec-json-schemas](https://github.com/asyncapi/spec-json-schemas) repository. @@ -140,7 +140,7 @@ An example of doing this is: - this [commit from the 2.3.0 release](https://github.com/dalelane/spec-json-schemas/commit/9cff7798ac42f609927e1cb9e532ff16d360ab99) - this [pull request from the 2.3.0 release](https://github.com/asyncapi/spec-json-schemas/pull/139) -#### Update the list of AsyncAPI schema MIME types with the new version +#### Step 4.4 - Update the list of AsyncAPI schema MIME types with the new version Repository: [parser-js](https://github.com/asyncapi/parser-js) The file to be updated is `lib/asyncapiSchemaFormatParser.js` in the [parser-js](https://github.com/asyncapi/parser-js) repository.