feat: add autoware_version_manager package

[xmfcx]

Description

Continuation of discussion in:

• refactor: use control_cmd_auto instead tier4/scenario_simulator_v2#1020 (comment)

Related to (depends on):

• feat(autoware_system_msgs): add version service messages autoware_msgs#71

Related issue:

• refactor(autoware_auto_control_msgs): replace autoware_auto_control_msgs with autoware_control_msgs autoware.universe#3674

Tests performed

You should merge:

• feat(autoware_system_msgs): add version service messages autoware_msgs#71

before testing.

Compile and run it with:

$ ros2 launch autoware_version_manager autoware_version_manager.launch.xml
[autoware_version_manager_exe-1] [INFO 1689353411.197970986] [autoware_version_manager]: Autoware version: 2023.07.0 (AutowareVersionManagerNode() at /home/mfc/projects/autoware/src/core/autoware.core/autoware_version_manager/src/autoware_version_manager_core.cpp:54)
[autoware_version_manager_exe-1] [INFO 1689353411.198022887] [autoware_version_manager]: Component interface version: 1.0.0 (AutowareVersionManagerNode() at /home/mfc/projects/autoware/src/core/autoware.core/autoware_version_manager/src/autoware_version_manager_core.cpp:58)

You can call the services:

$ ros2 service call /get_version_autoware autoware_system_msgs/srv/GetVersionAutoware
requester: making request: autoware_system_msgs.srv.GetVersionAutoware_Request()

response:
autoware_system_msgs.srv.GetVersionAutoware_Response(year=2023, month=7, micro=0)

$ ros2 service call /get_version_component_interface autoware_system_msgs/srv/GetVersionComponentInterface
requester: making request: autoware_system_msgs.srv.GetVersionComponentInterface_Request()

response:
autoware_system_msgs.srv.GetVersionComponentInterface_Response(major=1, minor=0, patch=0)

Pre-review checklist for the PR author

The PR author must check the checkboxes below when creating the PR.

• I've confirmed the contribution guidelines.
• The PR follows the pull request guidelines.

In-review checklist for the PR reviewers

The PR reviewers must check the checkboxes below before approval.

• The PR follows the pull request guidelines.

Post-review checklist for the PR author

The PR author must check the checkboxes below before merging.

• There are no open discussions or they are tracked via tickets.

After all checkboxes are checked, anyone who has write access can merge the PR.

[xmfcx]

(Edited after revision)
@isamu-takagi do you think we can go with following versioning schemes?

# Autoware version (CalVer with YYYY.0M.MICRO)
# https://calver.org/#scheme
autoware-version:
  year: 2023
  month: 7
  micro: 0

# Autoware component interface version (SemVer)
# https://semver.org/
component-interface-version:
  major: 1
  minor: 0
  patch: 0

// Autoware version (CalVer with YYYY.0M.MICRO)
// https://calver.org/#scheme
struct VersionAutoware
{
  uint16_t year;   // year of release
  uint16_t month;  // month of release
  uint16_t micro;  // increments for bug fixes or patches
};

// Autoware component interface version (SemVer)
// https://semver.org/
struct VersionInterface
{
  uint16_t major;  // increments for breaking changes
  uint16_t minor;  // increments for non-breaking changes
  uint16_t patch;  // increments for bug fixes or patches
};

[xmfcx]

@mitsudome-r I've edited this post a couple of times to avoid confusion.

The current versioning scheme YYYY.0M has served us well so far, but with the increasing pace of development, it might be beneficial to refine it further.

Looking at different versioning schemes, I suggest we adopt a slightly modified approach for Autoware: YYYY.0M.MICRO. This scheme retains the clarity of our previous system, while also enabling us to track and version hotfixes.

Under this system, the YYYY.0M part will strictly represent the release date, devoid of any additional information, and the MICRO part will specify the hotfixes made on that release.

To deal with breaking changes, it might make sense to decouple the Component Interface version from the Autoware version. This would simplify tracking of breaking changes, as they would be tied to the Component Interface version, which could follow SemVer.

What is a breaking change for Autoware?

In the context of Autoware, I believe we need a clear definition of "breaking change".
I think that a breaking change would be anything that alters the Component Interface version, affecting compatibility.

The concept of breaking changes could extend to dropping support for certain sensors, but since we aim to maintain sensor manufacturer neutrality in Autoware, these changes wouldn't impact the Autoware version. This way, we maintain a clean distinction between the interfaces and the core system.

Looking forward to hearing your thoughts on these suggestions.

Some ideas generated by ChatGPT for a breaking change (not that it will affect the versioning system mentioned above)

Breaking Changes

1. Changes to the API: Any significant changes to the software's Application Programming Interface (API) could constitute a breaking change. If a function's parameters, return values, or behavior is altered in a way that existing code will no longer work correctly, this would be a breaking change.

2. Altering Core Functionality: If a key feature or functionality of the software changes drastically enough that it requires users to modify how they interact with the software, this could be considered a breaking change. For example, changes in the driving or mapping algorithms that would require a significant recalibration or reconfiguration.

3. Deprecation of Features: If a feature or component that users depend on is removed, it could constitute a breaking change. For example, dropping support for certain communication protocols or sensor interfaces that some users rely on.

4. Dependency Updates: If Autoware depends on other software libraries, and those dependencies are upgraded in a way that requires the user to also upgrade those dependencies, this could be considered a breaking change.

5. Changes in System Requirements: If newer versions of Autoware require different or more advanced hardware or software environments (e.g., newer OS, higher compute resources), that could be a breaking change for users with existing setups.

6. Significant Changes in Configuration or Installation Process: Changes that alter how Autoware is installed, set up, or configured might be considered breaking changes if they require users to significantly adjust their processes.

7. Incompatible Data Format Changes: Changes to the formats of data that Autoware imports or exports could be a breaking change if they're not backwards compatible.

[xmfcx]

@isamu-takagi -san this PR is ready for review, after the review, I will populate the readme file with instructions.

I am open to any kind of suggestions, version schemes, the way they are stored, fetched, anything basically.

Thanks for reviewing.

[HansRobo]

This package is great for getting the version at runtime!
On the other hand, some software can write more efficient and cleaner code by getting the version at compile time.

So how about generating hpp files based on version-autoware.yaml and version-component-interface.yaml when building this package?

Note: It's fine to separate the implementation of this proposal from this pull-request.

[isamu-takagi]

I think it's good to manage versions for each component/scope. For example, even if the interface for the vehicle driver changes, the sensor driver want to keep the version.

[xmfcx]

@HansRobo @isamu-takagi Now I am working on an implementation for generating the version header files. For this, I will restructure this package as follows:

• autoware_version_manager (folder)
  • autoware_version_manager (package, will serve the services)
  • version_header_generator (package, will be used to generate the headers)

version_header_generator

This package will contain the jinja2 templates and the python executables that will generate the headers.

These will read the version .yaml files to generate the headers.

Will be similar to generate_parameter_library_py in functional sense.

autoware_version_manager

This package will call the executables of version_header_generator in compilation time using custom cmake functions, similar to generate_parameter_library.cmake.

The generated headers will be shared with outside nodes from this package.

And in the runtime, it will use the version information from the generated headers and serve this information to other nodes.

Do you think this is a good structure/plan to implement this?

[xmfcx]

I think it's good to manage versions for each component/scope. For example, even if the interface for the vehicle driver changes, the sensor driver want to keep the version.

@isamu-takagi I think it's a good idea but also challenging to implement.

We should define what Autoware really uses for each interface. (For each component.) (autoware_x_msgs, autoware_auto_x_msgs, tier4_autoware_msgs etc.)

Edit: I've just seen your work on this topic:

• feat(component-interface): add component interface list autoware-documentation#279
  Thanks for starting the work on this!

Until then I suggest we start with a large scope version for the interface. What do you think?

[xmfcx]

Related: Clarify update rules for component interfaces

[stale]

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

[xmfcx]

I'm closing all of my message migration PRs.