realsense2_camera: 4.0.3-1 in 'galactic/distribution.yaml' [bloom] (r…

…os#32473)

* realsense2_camera: 4.0.3-1 in 'galactic/distribution.yaml' [bloom]

* Update source branch

Add Fedora and RHEL rules for python3-rtree (ros#32369)

leo_robot: 2.1.1-1 in 'noetic/distribution.yaml' [bloom] (ros#32415)

eigenpy: 2.6.11-1 in 'noetic/distribution.yaml' [bloom] (ros#32301)

Skip releasing rosbag2_bag_v2 on Rolling. (ros#32262)

This package cannot build without a ROS 1 workspace and the ROS 1
bridge.

See ros2/rosbag2_bag_v2#46 for details.

rviz: 1.14.14-1 in 'noetic/distribution.yaml' [bloom] (ros#32143)

ntrip_client: 1.0.1-1 in 'noetic/distribution.yaml' [bloom] (ros#32123)

[migration-tools] Always release source version with updated release …

…increment instead of last_version. (ros#32112)

* Always release source version and source increment + 1 instead of last_version.

When performing the Rolling platform migration several repositories had bloom releases which were not committed to the distribution file at the time of the source ref.
As a result the `last_version` entries for those repositories did not match the release version in the source distribution during migration.
Since the migration tool was using the last_release in order to handle any releases that were not hard coded to a specific version and/or release tag this created a split between what was performed by git-bloom-release during migration and what was configured in the resulting distribution file.

One example is the ros2_control repository which had a 2.2.0-1 release made in ros2-gbp/ros2_control-release@7504ac3 but which never received a rosdistro PR.
Thus the migration tool released 2.2.0-2 based on the last_release information in the tracks file but the source distribution was anticipating 2.1.0-2.

Of the changes in this commit I am most hesitant about the release_increment handling since this script will eventually generate and force push updated release artifacts and if in a similar situation a 2.1.0-2 was released but not published in the source distribution file its artifacts would be clobbered where they overlapped with the migration-tool's own 2.1.0-2.
However I don't have a method of resolving that situation without searching each release repository's artifacts for a full list of release increments associated with a version.

* Increment the greater between the source distribution increment and current release increment.

Reduce the likelihood that the migration will clobber existing release tags by incrementing the greater between the source distribution increment and the current release increment in the Bloom track.
There are still situations where a release could be clobbered which has been documented but left unhandled.


Co-authored-by: Scott K Logan <[email protected]>

Update velodyne_simulator release repository. (ros#32104)

vision_opencv: 3.0.2-2 in 'rolling/distribution.yaml' [bloom] (ros#31942

)