Defining version control for Autoware

[mitsudome-r]

Code of Conduct

• I have read CODE OF CONDUCT and Support Guidelines before creating this Discussion post.

Contents

Background

Since this year, we have started to release autoware_msgs as a ROS package and started to put version tags to autoware_msgs. However, we haven’t been clear about the rules about version control for the repository so I would like to propose a release cycle and rules about changes to autoware_msgs to have a controlled version.

Proposal for version control

Major Version

• We update major versions only if we have breaking changes in autoware_msgs.
  • This includes modification in message field name, deletion of a field in a message, change in package names, etc.
  • The details are shown in this discussion
• We update major versions once a year.
  • Since we started a release as a ROS package, we would like to keep the code compatible within the same ROS distribution.
  • We could also give heads up to the users about the breaking changes by having a fixed release schedule.
    • We will block any PRs that would make breaking changes to autoware_msgs until 1 month before the release date of the next release. When the release date approaches, we will create a dev-branch to test all the breaking changes PRs.

Minor Version

• Any changes that do not make breaking changes to autoware_msgs can be merged anytime as long as they pass all the CIs and will be released as minor versions.
• We will release the minor version bi-weekly
  • We can skip the release if there are no updates

autoware.repos file management

We will specify the version tag instead of a branch name in autoware.repos (This is already done in the latest main branch) The specified version will be automatically updated by the task in this discussion.

If everyone is okay with the above rules and operations, I would like to apply similar rules to other repositories maintained by AWF.