[jazzy] Update to version 2.1.3 of mcap and rosbag2_storage_mcap docs

[Hpeox]

Description

This PR updates the vendored MCAP source in mcap_vendor on the jazzy branch from releases/cpp/v1.3.1 to releases/cpp/v2.1.3.

It also removes the obsolete GCC 15 patch from mcap_vendor, since the corresponding include is already present upstream in
releases/cpp/v2.1.3.

In addition, it updates the rosbag2_storage_mcap documentation to keep it in sync with the MCAP documentation。

This change follows the Rolling PR #2355 .

Is this user-facing behavior change?

No

Did you use Generative AI?

ChatGPT 5.4, helping draft PR descriptions and assisting with local build and test validation.

Additional Information

Local validation on ROS 2 Jazzy:

• colcon build --packages-up-to rosbag2
• colcon test --packages-up-to rosbag2

Additionally smoke-tested on local RealSense hardware by recording one camera's RGB and aligned depth topics to MCAP, verifying the result with ros2 bag info, and successfully running ros2 bag play on the recorded bag.

[MichaelOrlov]

@Hpeox Can you please clarify the reason for mcap_vecndor_package update on Jazzy?

We generally avoid updating vendor packages in released ROS 2 distros unless the change is a narrowly scoped bug/security/compatibility fix, because vendor bumps can violate ABI stability or change recording/replay behavior or introduce new bugs.
Also, we are trying to keep the same version as in the binaries in the relevant Ubuntu release to avoid downloading and compiling vendor packages from sources during each CI job run.

[Hpeox]

@Hpeox Can you please clarify the reason for mcap_vecndor_package update on Jazzy?

We generally avoid updating vendor packages in released ROS 2 distros unless the change is a narrowly scoped bug/security/compatibility fix, because vendor bumps can violate ABI stability or change recording/replay behavior or introduce new bugs. Also, we are trying to keep the same version as in the binaries in the relevant Ubuntu release to avoid downloading and compiling vendor packages from sources during each CI job run.

Thanks for the clarification.

I understand the ABI / behavior stability concern for vendor bumps in released distros, and my intent here was to keep the change as small as possible.

While looking into MCAP chunk behavior on Jazzy, I noticed that the vendored cpp/v1.3.1 release notes and the actual tagged source did not appear to line up for the writer-side behavior I was investigating. In particular, the cpp/v1.3.1 release notes refer to the writer-side changes introduced in PR #1291 and the related follow-up fix in PR #1375, but I could not reconcile that with the tagged writer-side source.

In practice, I was trying to rely on the newer upstream MCAP behavior / fixes in this area. Since Rolling had already moved to cpp/v2.1.3, I treated this as a minimal backport rather than a new divergence on Jazzy.

So I tried to keep the change as small as possible:

• update the vendored MCAP tarball to cpp/v2.1.3
• remove the obsolete patch

[MichaelOrlov]

@Hpeox Am I understanding correctly that there is nothing broken? It is just label cpp/v1.3.1 inside the mcap sources repo was incorrectly pinned, i.e., doesn't correspond to the release notes?

[Hpeox]

@Hpeox Am I understanding correctly that there is nothing broken? It is just label cpp/v1.3.1 inside the mcap sources repo was incorrectly pinned, i.e., doesn't correspond to the release notes?

Yeah, mostly. What I noticed first was mainly that the cpp/v1.3.1 tag, the release notes, and the source code I inspected did not actually line up.

However, this was not purely about newer features, and not just about the mismatch between the release notes and tagged source. There were also bug fixes between 1.3.1 and 2.1.3, like the UB fix in v1.4.1 and the McapWriter re-use fix in v2.0.2.

[MichaelOrlov]

From one hand I would oppose to the movement to this updated for the mcap vendor package since we have a policy to not update vendor packages in the already released ROS distros and it bumps major version from 1.3.1 up to the 2.1.3 which is certainly will have ABI incompatible changes inside.
However, from another hand if it will solve someones problems and bring a real bug fixes and improvements I would vote for it.
I am also trying to consider an implication of the ABI incompatibility.
MCAP vendor package lying at the very bottom of the dependency chain. May be I am wrong, and please correct me if so, but I don't envision of what can go wrong if it will not inherit ABI compatibility.

Given the consideration above I would like to hear a second opinion in regards this mcap_vendor package update proposal.
cc: @clalancette @mjcarroll Can you please express your opinion?

[mjcarroll]

We discussed this in the PMC meeting this week.

I believe that increasing a major version in a released LTS without a strong reason is probably not the way to go. I don't see any evidence that there is a critical bug being fixed here. While mcap_vendor may work fine for rosbag2, it is also likely that other people are depending on the mcap_vendor package for their development and this could cause ABI breaks.

If you absolutely need the newer mcap version in your Jazzy setup, I would suggest this is probably the right time to fork the package here.