Prepare for 1.0.0 Release

[azeey]

🎈 Release

Preparation for 1.0.0 release.

Comparison to 0.246.0: 0.246.0...ros2

General notes about our release scheme

We used to have a version scheme where each number in the version identified which version of ROS and Gazebo it was targeting. We were also releasing packages into packages.osrfoundation.org as well as packages.ros.org, although it looks like at some point we stopped doing and instead started releasing deb packages like ros-humble-ros-gzgarden where the name of the Gazebo release was included in the package name.

Going forward, I propose we only support the official Gazebo/ROS pairing (1:1 pairing) for making ros_gz releases. We would release the official ros_gz debs into packages.ros.org and if we do make additional binaries for unofficial Gazebo/ROS parings at packages.osrfoundation.org, we'd continue to including the Gazebo release in the package name, so the version number can stay the same.

Notes about 1.0

With the proposal above, after discussing with @mjcarroll, it makes sense to release 1.0 into Rolling. ros_gz has been fairly stable for a while. Most changes are adding new message converters or otherwise non-breaking. The only potential breaking change I see coming down the pipe is if we implement the ability for users to register their own message converters. Even then, since we currently don't really have a public API (installed headers are mostly message converters), that change probably won't break any users.

I'm open to feedback. I'll wait for ✅ from @ahcorde , @j-rivero and @mjcarroll before merging.

Checklist

• Asked team if this is a good time for a release
• There are no changes to be ported from the previous major version
• No PRs targeted at this major version are close to getting in
• Bumped minor for new features, patch for bug fixes
• Updated changelog
• Updated migration guide (as needed)
• Link to PR updating dependency versions in appropriate repository in gazebo-release (as needed):

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

[mjcarroll]

Our little baby is all grown up!

[j-rivero]

We used to have a version scheme where each number in the version identified which version of ROS and Gazebo it was targeting.

If I remember correctly having the version schema using numbers differently in each version of ROS was to avoid ROS release conflicts (i.e: version X.Y.Z in the Iron branch generates tags and metadata for Iron and a hypothetical same version X.Y.Z in the ros2 branch will conflict when generating the release for Rolling). See the moveit example.

Going forward, I propose we only support the official Gazebo/ROS pairing (1:1 pairing) for making ros_gz releases. We would release the official ros_gz debs into packages.ros.org and if we do make additional binaries for unofficial Gazebo/ROS parings at packages.osrfoundation.org, we'd continue to including the Gazebo release in the package name, so the version number can stay the same.

This seems possible and what I've been doing lately. Only minor detail is that we need to use version X.Y.Z-R to generate the wrappers in bloom thus we need to use a different release Rversion, typically R+1.

[j-rivero]

With the proposal above, after discussing with @mjcarroll, it makes sense to release 1.0 into Rolling.

Do we want to document it in the version scheme document or the plan is to remove that document in favor of other practices for keeping version numbers?

[azeey]

Before releasing 1.0.0, we should probably move headers around/use PIMPL so we don't have to freeze our ABI.

[azeey]

I've updated this to include the gz_vendor_pkg changes. This is ready for another look. I'd like to release this today if possible.

Before releasing 1.0.0, we should probably move headers around/use PIMPL so we don't have to freeze our ABI.

It looks like the installed headers could actually be used (e.g. #511), so I'll leave them as is.

If I remember correctly having the version schema using numbers differently in each version of ROS was to avoid ROS release conflicts (i.e: version X.Y.Z in the Iron branch generates tags and metadata for Iron and a hypothetical same version X.Y.Z in the ros2 branch will conflict when generating the release for Rolling). See the moveit example.

From my conversation with Chris, the core packages deal with this by always doing the following:

• Stable branches only get patch bumps, even if there is an API change. This does not follow semver, but it's needed for this scheme to work
• The unstable branch (ros2 or rolling) gets a minor or major bump right after a new ROS release is made. E.g. Once Jazzy is released, all the rolling branches will get a minor bump for their next bloom release even if the change warrants a patch release. This avoids the tag conflict you mentioned.

I think we should follow the same versioning scheme since it seems to work well for the ROS team.