Second phase of improving the release process for autoware.universe and autoware_launch

[youtalk]

First phase of improving the release process for autoware.universe and autoware_launch

In the previous post https://github.com/orgs/autowarefoundation/discussions/5292, we suggested reflecting the version management of the forked repositories, tier4/autoware.universe and tier4/autoware_launch, in the upstream repositories, awf/autoware.universe and awf/autoware_launch. This has already been implemented, and version releases 0.38.0 and 0.39.0 have been carried out.

• chore(package.xml): bump version to 0.39.0 autoware.universe#9435
• chore(package.xml): bump version to 0.39.0 autoware_launch#1248
• chore(autoware.repos): fix autoware.universe and autoware_launch versions to 0.39.0 #5479

However, the current release process involves reflecting changes in the upstream repositories via the tier4 forked repositories, which leaves challenges such as resolving merge conflicts and discrepancies in release timing.

Second phase of improving the release process for autoware.universe and autoware_launch

Therefore, as the second phase of improving this release process, we will first introduce a change to create a PR in the upstream main branch by running catkin_generate_changelog and catkin_prepare_release --no-push. This change will prevent the merge conflicts and minimize discrepancies in release timing.

This change to the release process is scheduled to be applied during the release of the next version, 0.40.0.
This improved release process was consolidated based on discussions with @xmfcx @mitsudome-r @rej55 @sasakisasaki. Thank you very much!

[mitsudome-r]

Maybe having TIER IV fork repo might seem confusing to most of the users so I will explain it how it looks in the AWF repository.

I think the basic steps for the release process are the following:

• When we are going to prepare a release, we first create a pull request to the main branch to update CHANGELOG.rst and the versions in package.xml for the next version.
• Once it is merged, we will sync the humble branch with the main branch
  • we allow merging with merge commits (not squash commits) to avoid conflicts for this
• We do the tests against the humble branch. If there is a hot fix required, we merge the patch first to main branch, then cherry-pick it to humble branch
• Once we confirm that humble branch is working, we put a tag to the humble branch which could be referred from autoware.repos file.

The TIER IV fork in @youtalk's diagram is just there to show that TIER IV engineers will help out the release with additional tests in their repo before putting a tag.