[Proposal] Define message type update procedure

[isamu-takagi]

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

This will require Autoware developers to support message adapters.

Currently, when a message type is changed, software that use Autoware will need to be updated immediately.
This reduces the maintainability of the software, so we will introduce a mechanism to support compatibility.

Related:

• https://github.com/orgs/autowarefoundation/discussions/3922
• https://github.com/orgs/autowarefoundation/discussions/3668.

Purpose

Enable smooth interface migration for software that use Autoware.

Possible approaches

Prerequisites

• This procedure assumes a certain degree of compatibility for most interface changes. So discuss separately for breaking interface changes that cannot be covered by message adapter.

Preparation

• Clone the latest message and release it as a versioned message.
• Create a node to convert to a versioned message.
• Add a topic with versioned messages named like /<original-topic-name>/v1

Follow the rules below when changing message:

• Free to modify the latest message as long as conversion to/from versioned messages is supported.
• To remove old versioned message:
  1. Clone and release the latest message.
  2. Decide on a migration period for the message.
  3. Support conversion to both old and new versioned messages during the transition period.
  4. Remove old versioned messages once the transition period is over.

Optional Features

• It is useful to have a file detailing the support period for the interface so that the software knows when migration is necessary.

Definition of done

• Clone and release the latest message.
• Add adapter node and versioned topics

[stale]

This pull request has been automatically marked as stale because it has not had recent activity.