Work on 2.4.1 release

[smoya]

Release 2.4.1 is scheduled for July 2022

Detailed info:

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

Potential work to be included in this version

Accepted

• feat: allow re-usability of Server Variable Objects #776

Progress:

- [ ] Create release branches
- [ ] Update release branches with new versions
- [ ] Update default branches with release branch name
- [ ] Create draft release notes
- [ ] Update release branches from forks
- [ ] 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
- [ ] Notify tsc_members about upcoming release

• Merge release branches into master
  • spec

- [ ] Write release notes for the releases on Github

• Create releases on Github
  • spec
• Update RELEASE_PROCESS doc with any changes

Cleanup tasks after the release

• [ ]

[smoya]

Please correct me if I'm wrong @derberg, this is our first minor version release. Meaning we should make some decisions on how we want to approach this.

In order to release, technically all we need to is to merge #776. This will trigger 2.4.1 version.
However, that's not all. There are some other tasks, based on RELEASE_PROCESS.md, we would need to decide if we do all of them, some of them, or none.

• Update version numbers in official examples
• Update version number in the spec
• Parser-JS: Update list of AsyncAPI Schema mime types with the new version
• Do a blog post announcement
• Prepare release notes
• Notify the community

IMHO, we could do all of the above.

What are your thoughts? cc @dalelane @derberg @fmvilas

[dalelane]

In theory, I think it's reasonable to do a subset to try and keep patch versions as cheap as possible. But in practice, other than the blog post, I don't think there is much that we can really skip.

[derberg]

looking at the list, I would ask is it worth the effort if we have 2.5 scheduled for September, so 1.5 month away

[smoya]

looking at the list, I would ask is it worth the effort if we have 2.5 scheduled for September, so 1.5 month away

For me, it is worth it if we end up defining the process for patch releases. It is something we could have at some point anyway (a more urgent fix might be needed eventually, for example).

[fmvilas]

I think it's very unlikely we'll have an urgent patch release to do in the future. The spec shouldn't have such urgency IMHO. Dunno, not worth the effort for me.

[smoya]

I think it's very unlikely we'll have an urgent patch release to do in the future. The spec shouldn't have such urgency IMHO. Dunno, not worth the effort for me.

Fair enough, TBH. A couple of things:

1. SemVer says the following for PATCH releases:

   PATCH version when you make backwards compatible bug fixes.
   [...]
   Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version.

   As far as I can see, critical changes that could be worth to release ASAP won't go into the PATCH but MINOR or MAJOR. So 👍 .

2. Would it make sense to mention somewhere (Maybe the RELEASE_PROCESS.md) AsyncAPI won't ever release PATCH versions?

3. Consider moving to <major>.<minor> versioning, like OpenAPI does.

cc @dalelane @derberg @fmvilas

[derberg]

AsyncAPI won't ever release PATCH versions?

I'm personally always afraid of such statements, I like saying never say never

the fix that we now say to do in a MINOR would normally by a PATCH. But because we are short from MINOR and other important things to do, we just say yeah, no need to really do anything here, especially because of holidays dead season, and we can easily just release the fix with other features in September

what I'm trying to say, this is still a PATCH but I don't see we are obligated to release it if it is not really critical and needed

[char0n]

Do I correctly assume that 2.4.1 release effort was discontinued? Given we already have 2.5.0 effort on the way.

[smoya]

@char0n your assumption is correct. Closing in favour of #830.