docs: add v3.1 release notes (#5034)

Co-authored-by: Lukasz Gornicki <lpgornicki@gmail.com>
Co-authored-by: V Thulisile Sibanda <66913810+thulieblack@users.noreply.github.com>

Author: derberg

markdown/blog/release-notes-3.1.0.md

@@ -0,0 +1,58 @@
+---
+title: AsyncAPI Spec 3.1.0 Release Notes
+date: 2026-01-31T19:00:00+01:00
+type: Communication
+tags:
+  - Specification
+  - Release Notes
+cover: /img/posts/release-notes-3.1.0/cover.webp
+authors:
+  - name: Lukasz Gornicki
+    photo: /img/avatars/lpgornicki.webp
+    link: https://www.linkedin.com/in/lukasz-gornicki-a621914/
+excerpt: 'AsyncAPI 3.1 is now released with a new ROS 2 binding.'
+featured: true
+---
+
+The new version of the AsyncAPI specification - 3.1.0 - is now available. It looks like we are out of the long break after v3 release.
+
+> This is a minor release, and it doesn't bring any breaking changes. You can switch to it by modifying the following value in your AsyncAPI file `asyncapi: '3.0.0'` into `asyncapi: '3.1.0'` without any issues.
+
+
+## New protocol bindings
+
+The specification is now extended to support another custom protocol through the bindings feature:
+
+ROS 2 ([official docs](https://docs.ros.org/en/jazzy/)), thanks to [@gramss](https://github.com/gramss) and [@amparosancho](https://github.com/amparosancho).
+
+For more details, check out [ROS 2 binding definition](https://github.com/asyncapi/bindings/tree/master/ros2).
+
+## Tooling support
+
+The following official AsyncAPI tools are already updated to support the 3.1.0 version of the specification:
+- JSON Schema that supports validation of AsyncAPI documents with ROS 2 binding is updated in [this](https://github.com/asyncapi/spec-json-schemas/releases/tag/v6.11.1) repository. Also **@asyncapi/specs** package has been updated on NPM to version 6.11.1.
+- [JavaScript Parser](https://github.com/asyncapi/parser-js/releases/tag/%40asyncapi%2Fparser%403.6.0) uses latest **@asyncapi/specs** package and can be used to parse and validate 3.1.0 documents. Upgrade to the latest version.
+- [JavaScript Converter](https://github.com/asyncapi/converter-js/releases/tag/v1.7.0) uses latest **@asyncapi/parser** package and can be used to convert to 3.1.0 documents. Upgrade to the latest version. This conversion is just the version change in `asyncapi` field.
+- [AsyncAPI Studio](https://github.com/asyncapi/studio) is also updated so just go to https://studio.asyncapi.com/ and see you can already write 3.1.0 documents.
+
+## Thank you
+
+Huge thanks to contributors of the new addition to the spec: [Amparo Sancho Arellano](https://github.com/amparosancho) and [Florian Gramß](https://github.com/gramss).
+
+Huge thanks to specification maintainers that supported the process: [Fran Méndez](https://github.com/fmvilas), [Dale Lane](https://github.com/dalelane), [Vladimír Gorej](https://github.com/char0n), and [Lukasz Gornicki](https://github.com/derberg).
+
+Huge thanks to maintainers that helped with smooth updates of core tooling: [Maciej Urbańczyk](https://github.com/magicmatatjahu), [Ashish Padhy](https://github.com/Shurtu-gal), [Pavel Bodiachevskii](https://github.com/Pakisan), [Fran Méndez](https://github.com/fmvilas).
+
+And I ([Lukasz Gornicki](https://github.com/derberg)) was your release coordinator, and I just gave myself a round of applause.
+
+## Look ahead
+
+We now regularly meet to work on the AsyncAPI specification, and anyone is welcome to join. Meetings are coordinated through [this GitHub issue](https://github.com/asyncapi/spec/issues/1131).
+
+Next topics on the agenda:
+- [Documenting channels with late or out-of-sequence events](https://github.com/asyncapi/spec/issues/1143):
+    For folks with experience in streaming, frameworks like Apache Flink or Apache Spark, please look into this proposal to add the possibility of specifying expected event delivery latency to AsyncAPI contracts.
+- [Support AND logic for multiple security schemes](https://github.com/asyncapi/spec/issues/1129): Currently, AsyncAPI allows you to specify a list of security mechanisms where only one must be satisfied. The idea is to also allow users to specify that multiple mechanisms must be satisfied.
+- [Discriminator support to be aligned with OAS3](https://github.com/asyncapi/spec/issues/1073): Right now, the discriminator field in AsyncAPI is just a string, which is too limited. People end up using it in combination with const as a workaround. We should consider aligning with the OpenAPI Discriminator Object, but we also need to address the fact that the discriminator is and would be limited to the AsyncAPI Schema. We need a solution that works for people using other schema formats, like Avro or Protobuf, for example.
+
+> Photo by <a href="https://unsplash.com/@88pae?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Chinapat Saegang</a> on <a href="https://unsplash.com/photos/a-black-and-white-photo-of-a-large-city-gZJT5_k4LYY?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>

markdown/docs/concepts/asyncapi-document/adding-messages.md

@@ -3,7 +3,7 @@ title: Adding messages
 weight: 140
 ---
 
-In an AsyncAPI document, adding [messages](/docs/reference/specification/v3.0.0#messageObject) mainly means setting up channels and operations. This is key for explaining how data moves between your applications. However, sometimes you might just want to use the AsyncAPI document to describe the messages themselves, without anything else.
+In an AsyncAPI document, adding [messages](/docs/reference/specification/v3.1.0#messageObject) mainly means setting up channels and operations. This is key for explaining how data moves between your applications. However, sometimes you might just want to use the AsyncAPI document to describe the messages themselves, without anything else.
 
 ## Add messages
 
@@ -72,7 +72,7 @@ components:
                  description: Id of the comment that was liked
 ```
 
-You can reuse messages using the [Reference Object](/docs/reference/specification/v3.0.0#referenceObject). For example:
+You can reuse messages using the [Reference Object](/docs/reference/specification/v3.1.0#referenceObject). For example:
 
 ```yml
     messages:
@@ -82,7 +82,7 @@ You can reuse messages using the [Reference Object](/docs/reference/specificatio
 
 Here's the complete AsyncAPI document with channels reusing the same message:
 ```yml
-asyncapi: 3.0.0
+asyncapi: 3.1.0
 info:
   title: Example API
   version: '1.0.0'

markdown/docs/concepts/asyncapi-document/adding-operations.md

@@ -9,7 +9,7 @@ In an AsyncAPI document, operations describe your application's behaviors and ca
 
 ## Defining operations
 
-Operations can be defined as an independent object in the AsyncAPI document. More information about each field name that is used to define operations can be found [in the reference documentation of the specification](/docs/reference/specification/v3.0.0#operationObject). 
+Operations can be defined as an independent object in the AsyncAPI document. More information about each field name that is used to define operations can be found [in the reference documentation of the specification](/docs/reference/specification/v3.1.0#operationObject). 
 
 The following diagram declares the field names that are frequently used to define operations in an AsyncAPI document:
 

markdown/docs/concepts/asyncapi-document/dynamic-channel-address.md

@@ -58,7 +58,7 @@ components:
       description: The ID of the streetlight.
 ```
 
-You can reuse parameters using the [Reference Object](/docs/reference/specification/v3.0.0#referenceObject) like in the following example:
+You can reuse parameters using the [Reference Object](/docs/reference/specification/v3.1.0#referenceObject) like in the following example:
 
 ```yml
     parameters:
@@ -68,7 +68,7 @@ You can reuse parameters using the [Reference Object](/docs/reference/specificat
 
 Here's the complete AsyncAPI document with the channels' parameters for the `address` field:
 ```yaml
-asyncapi: 3.0.0
+asyncapi: 3.1.0
 info:
   title: Example API
   version: '1.0.0'

markdown/docs/concepts/asyncapi-document/extending-specification.md

@@ -16,7 +16,7 @@ Extensions can be used in any part of the AsyncAPI document.
 Here is an example of how to extend the AsyncAPI document with a custom property:
 
 ```yml
-asyncapi: 3.0.0
+asyncapi: 3.1.0
 info:
   title: Cool Example
   version: 0.1.0

markdown/docs/concepts/asyncapi-document/index.md

@@ -8,7 +8,7 @@ The [AsyncAPI specification](/docs/reference/specification/latest) defines field
 The AsyncAPI document is a communication contract between senders and receivers within an event-driven system. It specifies the payload content required for a service to send a message and provides the receiver with guidance about the message's properties.
 
 ```yaml
-asyncapi: 3.0.0
+asyncapi: 3.1.0
 info:
   title: Cool Example
   version: 0.1.0

markdown/docs/concepts/asyncapi-document/reply-info.md

@@ -37,7 +37,7 @@ In the case where you don't know the address of the reply yet, you have the opti
 For instance, this pattern allows the replier to direct its response to a specific channel as defined by the requestor. This is typically achieved by including a `replyTo` property in the request header. The requestor specifies this property to indicate where it expects to receive the response, guiding the communication flow in a structured and predictable manner.
 
 ```yml
-asyncapi: 3.0.0
+asyncapi: 3.1.0
 
 info:
   title: Ping/pong example for a requester with a dynamic reply channel
@@ -75,7 +75,7 @@ The request/reply pattern can also be implemented over multiple channels with a
 
 Here's an example of setting up both the requestor and replier over the same address:
 ```yml
-asyncapi: 3.0.0
+asyncapi: 3.1.0
 
 info:
   title: Ping/pong example with requester over the same channel
@@ -110,7 +110,7 @@ In some cases, representing the [same information](#multiple-channels-with-singl
 
 Consider an example where multiple messages are transmitted over a single channel, all sharing the same address. In this setup, the `Operation` object is utilized to distinctly specify which of these messages serves as the request and which functions as the reply:
 ```yml
-asyncapi: 3.0.0
+asyncapi: 3.1.0
 
 info:
   title: Ping/pong example when a channel contains multiple messages

markdown/docs/concepts/asyncapi-document/reusability-with-traits.md

@@ -96,5 +96,5 @@ headers:
 
 ## Trait merging mechanism
 
-In the AsyncAPI document, traits are merged into the operation or message object in the order they are defined, without overriding any properties. For detailed information on how this merging works, refer to [the specification's section on the traits merge mechanism](/docs/reference/specification/v3.0.0#traitsMergeMechanism).
+In the AsyncAPI document, traits are merged into the operation or message object in the order they are defined, without overriding any properties. For detailed information on how this merging works, refer to [the specification's section on the traits merge mechanism](/docs/reference/specification/v3.1.0#traitsMergeMechanism).
 

markdown/docs/concepts/asyncapi-document/reusable-parts.md

@@ -5,7 +5,7 @@ weight: 280
 
 Reusable parts in AsyncAPI provide flexibility, modularity, and code reusability. You can reuse the majority of document sections like messages, schema definitions, channels, operations, and more.
 
-Reusable parts allow you to split up the AsyncAPI document into many files and reference them using the [Reference Object](/docs/reference/specification/v3.0.0#referenceObject). You can use the `$ref` keyword to reference the same document, another local file, or an external URL. The diagram below describes how to reuse parts in AsyncAPI:
+Reusable parts allow you to split up the AsyncAPI document into many files and reference them using the [Reference Object](/docs/reference/specification/v3.1.0#referenceObject). You can use the `$ref` keyword to reference the same document, another local file, or an external URL. The diagram below describes how to reuse parts in AsyncAPI:
 
 ## Same document
 

markdown/docs/concepts/asyncapi-document/securing-operations.md

@@ -31,7 +31,7 @@ graph LR
 
 ## Operation section
 
-Security information for an operation is defined using a [Security Scheme](/docs/reference/specification/v3.0.0#securitySchemeObject) at the operation level. You can reference a scheme from another location, such as `components.securitySchemes`, using the `$ref` keyword.
+Security information for an operation is defined using a [Security Scheme](/docs/reference/specification/v3.1.0#securitySchemeObject) at the operation level. You can reference a scheme from another location, such as `components.securitySchemes`, using the `$ref` keyword.
 
 ```yaml
 operations: