did you add cpp tests?

Just added it now.

@azeey what's the process for getting this merged in and available for everything else that depends on it?
IE: gazebosim/gz-physics#638

@azeey what's the process for getting this merged in and available for everything else that depends on it? IE: gazebosim/gz-physics#638

For features involving pull requests to multiple repositories, I think the development process is easier to initially target the main branches (currently Ionic) and then backport. The reason it is easier is that we build nightly debians for Ionic on Ubuntu and build dependencies from source for macOS (windows is always built from source). When targeting a stable release, we would need to make a stable release or prerelease for the lower-level packages like gz-math in order to get working CI for higher-level packages like gz-physics. It especially can become a problem if we quickly merge and release a low-level package and then want to change its API/ABI based on insights from reviewing a higher-level pull request. Landing the whole feature on main first will hopefully stabilize the desired API so it can be backported.

EDIT: this is a policy that we had discussed recently but not added to our contributor documentation, so I have proposed adding it to our recommendations in gazebosim/docs#440

@ahcorde @scpeters here's the backport.

Thanks, @scpeters @azeey can I get this released so the other CIs can work?

Thanks, @scpeters @azeey can I get this released so the other CIs can work?

@bperseghetti the first step to making a release involves making a pull request to bump the version number and update the Changelog (see step 2 in the Gazebo Release Instructions - For Each Release). If you're interested to learn this process, that would be a good place to start.